TABLEUPDATE() returns .T. This is what is so frustrating about this problem, because there's no real trap for it. Everything seems to be normal, except that the data doesn't get written to the table. No error is even generated unless something programatically expects the record to be written explicitly.

I will try the FLUSH option after TABLEUPDATE() suggested. Turning off write-caching on all servers is not an option - I have software installed at many client sites. Few of the servers are dedicated to acting as a file share server for VFP software exclusively, and I can not specify to all IT managers that they need to implement this as a solution.

The problem is permanent - once the error happens it never gets corrected on it's own. If the problem were the cache wouldn't the file eventually get written?


>Eric,
>
>A mismatch of the headers record count and the number of records in the table is usually a result of the record being written but the header not being updated. Fox writes the data first and then writes to the header. If write caching is enable don tehserver it is possible that the record got written adn Fox wrote the header but it hasn't been saved by the write cache. This creates the very situation you describe.
>
>Another cause would be Fox crashing after the record write and before the header write. Out of curiosity, what is the return value from TableUpdate()?