Andy, Darren and Jim,

Usually, error 2072 happens when record in a cursor is modified (replace/insert) from underneath a grid or browse window and is not saved.
Saying "modified from underneath a grid", I mean it is modified/inserted by custom code (event handlers, valid,...) while focus stays in the grid. For example., SQL-INSERT leaves the last appended record "dirty" and this confuses the grid. To workaround this problem, the code that modifies the cursor should make sure that all modifications are saved. The simple way to do it is to move from that record GO TOP, GO BOTTOM, SKIP.

Thanks,
Aleksey.


>Andy and Darren,
>
>FYI (sorry, no help) I saw a report of the same error on the West-Wind message board too recently.
>
>In that case it was on an INSERT INTO to a cursor (i.e. a temporary table) that had just been zapped and NO views/DBCs/buffering involved. The only possible oddities (long shots I think) were:
>1) alias of the cursor was > 10 characters;
>2) the INSERT INTO did have a (new to VFP8) sub-select in it;
>3) the cursor was also the recordsource of a Grid.
>
>UPDATE: Worth mentioning that this person worked around it by opening the cursor AGAIN as a new alias and INSERTing to that alias instead.
>
>good luck
>
>
>>Darren,
>>Yes, I'm seeing this too since moving to VFP8. We're using VFE7.5b framework and it seems to happen mostly in cfield:value_assign on the REPLACE command. It makes no sense at all why this would be happening. Unlike you, our's is using remote views against SQL. We are also using localized "views only" dbc's so the DBC's themselves are not being shared by users on the network. I think we have buffermode = 3 on a lot of these views. I'd sure like to know what causes this and how to fix it. It's showing up more frequently in the errorlog, but I cannot successfully reproduce it in the test or developement environments.