>Timothy,
>
>buffering mode 2 is pessimistic row buffering and therefore any record movement will cause an automatic tableupdate by foxpro to be executed. The way to find the culprit would be to use the debugger and in the watch window put;
>
> RECNO("TheFile")
>
>then set a breakpoint on that expression by clicking in the left margin beside it. Now run you code and it will break whenever the record number in that table changes. I suspect that you will find that something in your form is moving the record pointer before you get to you tablerevert(). Because the table is updated when the pointer moves your revert has nothing to revert because the update has already occured.
>
>It is for this very reason that I only use Table buffering, with table buffering fox never does an automatic update and therefore I don't have to wory about one. I still design the interface so that only one record is ever dirty at a time, but I use table buffering.
>
>I can also give you some good arguments against pessimistic buffering as well. For one, wehn you append blank in pessimistic buffering a lcok is obtained and held on teh dbf header thus preventing any other station from adding a record until the first one is finished. This could be a real problem in a multiuser situation. The buffer mode that I use almost exclusively is 5 (optimistic table).

YOU GUYS were right!!! the record pointer WAS moving unbeknownst to me.
In the first field(editbox) of the form there was an old valid event that I had forgotten about! It moved the record pointer!!!!!!!!
!!!!!!!!!
!!!!!!!!!
!!!!!!!!!