>Thank you so much. That is exactly right.
>
>So, as you mentioned, it is where the change actually happened, and deal with it at that point.
>Trying to do the tableupdate() or tablerevert() as part of Error Handling, does NOT work. It just loops.
>
>The problem is, again as you guessed, this is happening once a day in 100's of transactions.
>To figure out what the operator did? - is the challenge!.
>
>Maybe I should put a tableupdate() every where there is a SEEK or a GOTO in the code?

No. When the error occurs, it is obviously on a particular table. I would record the state of that table at the beginning of a transaction to a log file of some kind. getfldstate might be a good thing. Then when the error happens - you should find what field changed. Then you should be able to find the code between the beginning of the transaction and the error message where a change was made to that table.

>
>Cyrus
>
>>>Using VFP8 in Multi-User environment submitting changes via Transaction.
>>>What is the best way to deal with:
>>>
>>>"Cursor cannot be modified because it contains unsaved changes" (error 2072).
>>>
>>>Error 2072 is not listed in VFP Help files. Can somebody explain exactly what is really happening?.
>>>I know if there are unsaved changes in memory, I can submit them to disk using TABLEUPDATE() - or discard them using TABLEREVERT()
>>>
>>>What I am not sure exactly is the mechanics of how the table gets into this state?
>>>
>>>Thanks
>>
>>Somewhere code made a change to the cursor. It may be intended or accidental. Since the change was not handled with a tableupdate, you get this error. Where that change happened is what you need to find. Clearing the change with either tableupdate or tablerevert at the point of the error message is the wrong thing to do. That's dealing with a symptom, not the cause.