>>No, we use transaction only when committing changes. E.g. first we made lots of insertions/replacements in lots of tables in buffering 5 mode and at the end of the process we commit all changes using transaction. Pretty much standard approach.
>
>IF you have a scenario reproducible on different machines with table located and indices recreated(!) on each machine, it might be worth your while to run the same scenario with transactions disabled. At least in vfp6 we had an issue with a setup just like you describe, where the frameworks methods (based heavily on table buffering) were not compatible with transactions. I am not involved with that project anymore and don't have access to the demo code causing the specific error (Chr(0) in many fields) to test against vfp9.
>
>You need to identify the bare bone factors causing the error and transactions, buffering and other table based actions didn't go together at least once in my expirience <g>.
>
>regards
>
>thomas


Thomas,

I can eliminate transactions in my tests, but I can not eliminate them in a real process otherwise I have a risk of messing up database pretty badly. I may disable RI, though (right now we're running with RI enabled which uses its own transactions). I was able to reproduce error on several machines, but not every time. I would say, I have this error on each thrid try with big (more than 5K) files.