Hi Eric,

>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.
>

Barbara Paltiel reported "oddball" problems with VFP I/O about a year ago now, though I cannot say that hers were precisely like yours. The one (of a few I think) that I remember was that an INDEX file would suddenly become unavailable).
I do recollect that the instances of the problem dropped very significantly once they dramatically reduced to server's print traffic. I'm afraid that I don't know if there was a "final" resolution to (all of) the problems.

>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.
>

I suppose that the FLUSH ought to be done after the END TRANSACTION and not after the TableUpdate(). It would be interesting to see what actually happened when you issued a FLUSH *during* a transaction, but I wonder if anything evident would present itself.

You may also find that most shops run their servers with write-cacheing DISABLED as a matter of course. It sure would hurt to ask (and it may help you to confirm further that this is *not* the problem).


>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?
>

As I've followed this I believe that you have this happen even when there is no recorded server crash or even a user pulling the plug on a workstation. Do you happen to know what network software these things happen on, and is it a variety or limited to one NOS only?

I would be very frustrate too!!!

Jim N


>
>>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()?