>BTW, once again we're talking about my colleague's code. Basically, at some point I helped him and we switched to select with BUFFERING = .t. Well, this turned out to be a disaster and a great slow down. I had a thread about it recently and with Fabio's help came to conclusion to not use this option if other means available.
>
>Then we made some other changes in the code and converted it to a class (not yet ready to move to production). I then took it to my hands and made bunch of other improvements (leaving the original logic intact). I also converted ProcessNewTrans to a class (this is I done on my own). Then I started extensive tests on the old batches and the problem appears on about every second try with a big file.
>
>In reality we're not going to re-load old batches, but it's not the point. The code should not produce this error. I tried old versions of the code (currently in production) and they gave the same error, so it's not my changes causing it.
>
>Right now I also asked another colleague (to sb - the ONE) to run a test. It is stil running on his PC, but I bet the second try would give the same error. His data are quite old...
>
>>>The problem is that the error is always in different places.
>>
>>I've re-read the whole thread, and at least four people said you should rebuild your indexes (not just reindex). I haven't found anywhere that you said you did, just that you believe SDT should be doing that.
>>
>>Well, are you postive that you're doing this with new set of indexes? Maybe you should make sure that SDT has gone through the recreation of indexes first, before trying anything else

I have the impression that the indexes get corrupt by a sequence of actions

A couple of things are worth trying

(1) limit the cache

=sys(3050,1, 64 * 1024 * 1024)
=sys(3050,2, 16 * 1024 * 1024)

(2) after every insert/update

flush
=sys(1104)

(3) go top, then seek


You'll quickly find out whether the above helps