>Nadya,
>
>Could the problem be the code BEYOND the "if m.lnTally > 0 && It should not happen"?
>
>Also, here the comment says 'should not happen' yet in another reply you seem to say you depend on it happening.

It should not happen in normal curcumstances, but I check for this to make sure and to prevent this 'uniqueness of indexes is violated' message. If it happens, I ask user, if he/she wants to delete records in BatchCntrl file....


>Also, I have seen reports that SET TALk can change the results of a few VFP variables, so you might want to try without TALK set ON.
>
>I have good results with _tally myself.
>
>good luck

Thanks, Jim. I've read a thread recently in Russian Forum about non-reliable behavior of _tally, it could be a problem here, I guess. I would probably comment out these set talk lines, because this select takes less than 2 sec. anyway.

I also added set deleted off before select statement per Hilmar's suggestion.

We'll migrate this project tonight and will see, if this helps.

BTW, I just found an interesting phenomena:
The same problem happened a week ago. At this time I thought, it could be a corrupted index problem. I opened this file exclusively, recreate index and made it primary (it was candidate before). Couple of minutes ago I copied this file from Live server to Development server, I just opened it and found, that the index is again candidate.

I believe, we have some really strange and nasty problem. Sometimes, some files reverted back to the prev. stage. I found several such occurences already, when my code, what I'm sure was changed, was reverted to the original state, and I have to re-do my changes again.

It really looks like we're working in some mystery tale...