>>Dragan
>>Glad you noticed that one last check. It may be required only on a theoretical level but I was getting some index corruption that seemed to be related to the recycling of records, so I wanted to make sure there wern't any gaps on my side when I started testing. We can never be sure when windows might terminate our time slice and give control to another process.
>>
>>I hear you ask in advance what the solution was to the index corruption ... Well I can't actually prove anything yet, but it appeared that my problem went away when I turned on buffering (type 3, but it shouldn't matter). As with the above, the corruption only showed up during VERY HIGH contention ... lets say 50 hits per second against the same table spread over 6 processes for example.
>>
>>Bob
>
>I wanted to ask what was the cause (if you ever found it - it may be yet another analysis/paralysis situation), but from your solution it seems to be that buffering (i.e. TableUpdate()ing) actually employs some better techniques than simple Replace or Gather may do. Good thing to remember, may save our necks some day.

Dragan
The cause is unknown, but I do have a solution based on some testing. I built a test that was busy adding and recycling records as fast as I could. It caused no index corruption. I tried running 3 copies of it (3 exe's) on the same machine. No corruption. But with 10 copies running, I could always produce a corrupted index within 10 minutes.

I then started varying anything I could think of in the indexes that I was using but none of it helped. I replaced CDX with IDX's, I removed all but one indexes in my CDX, I removed compound expressions in an index, I indexed on a datetime variable rather than ttoc(tDateTime,1), and I did a few more that I can't remember.

I then turned buffering on for the table I was working with, and threw in a tableupdate() after my REPLACE or INSERT INTO, and the corruption dissappeared. I then let it run for a weekend (54 hours and about 9 million insertions or recycles) and it worked.

That's about it. The only interesting side note is that it was working so hard, that two of my processes came up with a windows error complaining about being unable to write to a file because it already existed. It used one of those random names (both processes named the same random file name). It wasn't me creating the files, so I must have been going fast enough for windows' "guaranteed unique" filenames system to bump into itself. When I clicked OK on each stoped process's error message, they started going again and ran to completion.

I too would like to know what was really happening, but for now the pressure is off so I may not press this one any further for a while.

Good to chat with you Dragan

Bob