>I could buy that theory only in that the tables were opened exclusively. I say this because if the tables were opened shared and this were true, other users would view old values if they opened these tables after you had issued a tableupdate. What a mess that would be. If this theory is true, this method of internal data handling sucks. We should not have to issue a FLUSH to assure writes to disk when a TableUpdate should suffice.

Thanks for replies, guys. Yes, a corollary to my theory is that vfp only would do this for EXCLusively opened tables. It could not possibly be true in shared tables, we all have enough experience to that someone would have bumped into that long ago were it true. Server table EXCLs in apps are not too common, and I don't use them much, so it's possible the theory could be true and not shown up until now.

I've thought about trying FLUSH, but there's no documentation as to whether this will have any effect, as Jim noted. Might be worth a try, though it may be extremely difficult to test, if you think about it :) Another idea that would work, I'm certain, is a table close, if it can be done without interrupting the interface, but that may be a problem...

In the meantime, I'm going to warn users once more to NOT push the reboot button immediately when the screen appears to lockup. Often, it's only a temporary network hang, and other times a proper End Task might save the data, also.