>I thought of something more brutal - replacing field with itself may not do, so if what you propose doesn't flush it, I'd suggest harder measures:
>
>>=CURSORSETPROP('Buffering',1,'real_one')
>>USE real_one AGAIN IN 0 ALIAS temp EXCL
>REPLACE numericfield1 with -numericfield1 IN temp
>Flush
>REPLACE numericfield1 with -numericfield1 IN temp
>>USE IN temp
>>=CURSORSETPROP('Buffering',5,'real_one')
>
>Or even with buffering of Temp, and forcing a TableUpdate() after each replace...
>So, what were the results of testing this (short of extending the mercy of euthanasy to the server)?

That's what I really need, euthanizing the server :) I've ordered a fancy new 500 Mhz server with GBs of memory, huge caching, etc. I've had lots of trouble with the current Compaq 2500, ever since day one (the old 1500 was slower, but more reliable). LAN experts have spent hours on the 2500, but it still hangs and occasionally boots users off without apparent cause. I think that's really the root cause of the data loss.

But as far as above code testing, I have given up that idea for now...it may seem to work, but I can't tell easily and with certainty when local machines copy tables and do local Tableupdates, and when they don't (they usually don't).

Instead, I've found a few convenient places in the system to close and reopen the important tables during a user session, like in between form closing/opening, that's a 100% sure way to make sure server data gets refreshed occasionally...