>Faced with having to tell the user that the Audit-Trail says they "didn't" put the information when they swear blind that they did.
>
>What do you do in a situation like that? It's a nightmare!! Do you believe in the system, or do you believe in the user???

First, I always *tell* the user I believe them, whether I do or not, it makes for better future relations :-) Usually the users have some correct point about such a disaster, though often they are confused about what happened when, etc., when you press them for details.

More importantly, I've been through the same thing, about 2-3 years ago. A user claimed he had worked for an hour in an app of mine, doing all kinds of edits on one particular table, then had a PC crash, and all edits were lost in several tables.

This user's claim seemed impossible at first, as there are constant silent Tableupdates to both the "work" tables and the "audit" tables. However, I really did believe the user, as he was extremely upset, and he's normally a nice fellow. I've been through the same thing (it happened fairly often in the old mainframe days), and I know how aggravating it can be.

This led me to reconstruct what apparently occurred: The tables were small enough to fit in the local client memory, no one else had them open at the time (sort of "off-hours" when this user had been working, I think), and so the client and/or server evidently decided that it would use local caching for all the tableupdates until the tables were physically closed, and then it would push the data to the server. This does happen - I've seen it occur more than once, though it's uncommon.

The fix seems to have been to add FLUSH to a number of critical places in the app. I've never had another such complaint since I added the FLUSHes, and I use them in all such situations now.

Hope this helps a little.