The first one is just because you (probably) don't have an index expression that includes ".". If you're going to be search for terms with . in them a lot I would suggesting adding an index expression to index them. Maybe something like (there are lots of possibilities depending on what you want):
>>\alnum{1,99}\.=\alnum{1,99}
or
>>[\alnum.]{1,99}
The second indicates the new list of the index doesn't agree with the format of the index. The index needs to be rebuilt. There's a small chance of a race condition in older versions when adding/updating rows at the same time an index update kicks off. Current versions don't have that problem.
I actually do exactly that in order to properly index for expressions containing a period. Also, it is not possible in my process for a record to be inserted and updated at the same time. In fact, I don't even do updates. I delete and them timport in the case of an update.
I do periodic timports and then re-run my index scripts. So basically I do updates through periodic batches rather then real time. Would it be possible for monitor or chkind to be interfering in some way with this and causing this problem?
I meant updating the index at the same time as inserting/updating a record. If you have chkind running, either manually or via monitor (texis.cnf) it could start an index update at any time. If you're in the middle of a timport the odds of the race occuring are much higher. If you only load in batches chkind (automatic index update) should generally be turned off and you can do the update manually at the end of the load.
