>Fox isn't going to be the problem here. This problem has been reported in certain network configurations:
>
>- Older Netware drivers. Make sure you are using the latest drivers or use the Microsoft drivers.
>- Write caching on the server. This is a drive controller setting. It should be off.

I'm not so sure about this Craig. At least those aren't the only possibilities... have a look at KB Q293638 and thread #508276.

I suspect maybe that transactions are not as "bulletproof" as they could be.

There was also another message that I can't find that offers a bypass for some stuff LIKE this, and that is to put an Integer field and a 10-char field as the first 2 fields of a table. I *think* this applied when integter keys are involved.


>
>>I rewrote my companies major product in VFP6 and now in VFP7 using the Stonefield Database toolkit and the DBC. I thought that by doing this the troubles that I had occasionally had in FoxDOS where sometimes postings to multiple tables would not complete posting would be a thing of past (records written in one table but not another). Think again! The problem remains, perhaps worse. I know that the records get written because they are wrapped in bullet proof transactions, but records just disappear. I am told that this is because of header or index problems, but the why of the thing makes little difference. To make matters worse, I am now rewriting an inhouse app not using the DBC and am finding that screens come up MUCH faster and that not having to worry about buffering etc makes the code much simpler. The 'Scatter Name' command is a great enhancement to 'scatter memvar' because it solves the scope problem. Without the DBC and Stonefield managing updates is more problematic but I had
>>7 years of experience in DOS with doing that and have canned routines to handle just about every problem. I wish I had never heard the term 'primary key'. If I had a simple way to rip the DBC out of my app I would do it in a heartbeat. I would appreciate the views of others on this subject.