It is good practive to ALWAYS include the alias name in table operations (like you are already doing in REQUERY(). IOW,

TABLEUPDATE(0,.F.,"LV_AgenciesUPdate")
TABLEREVERT(.T.,"LV_AgenciesUPdate")

This way, we know for sure which cursors are being operated on. It looks to me like that is the problem; oyu have tred to TABLEREVERT() a different cursor tan you think you are.


>Ok, I am executing my TableUpdate() and detecting a failure. I want to tell the user it failed and requery the view to show them the current values (that were changed out from under them). I use the following code:
>
>IF !TableUpdate( 0, .F. ) && write changes - detect if someone else made a change
> =TableRevert( )
> WAIT WINDOW cUpdateFailed + " - " + cOtherUpdate + cNewLine + "Try again"
> =REQUERY( "LV_AgenciesUpdate" )
> .AgencyGrid.Refresh()
>ELSE
> . . .
>
>I get the following error (with or withOUT the TableRevert() line):
>
>Table Buffer for alias "lv_agenciesupdate" contains uncommitted changes
>.
>.
>.
>=REQUERY( "LV_AgenciesUpdate" )
>
>What should I be doing to clear the uncommitted changes? or is there another way to handle this?
>
>TIA, J
>
>>>I've been investigating using GetFldState. Does this function pertain to views? It just hit me, though, that GetFldState will give me info about the VIEW and not the underlying data, right?
>>
>>Yup. Works just like for a buffered table. GETFLDSTATE returns info pertaining to the status of the data in the view.
>>
>>
>>>Should I be using CurVal(), OldVal() to check the underlying table fields? but I thought that w/updateable views the idea was to only deal w/the view, not the underlying table data directly.
>>
>>I don't think oyu can get CURVAL() and OLDVAL() to work like this. To be honest, without opening another copy of the table, I don't know how to check these values. Most of the systems I write, the client has asks that the most recent changes win, so I just force the TABLEUPDATE(). But in cases where the rules are not that simple, when an update conflict occurs, I just inform the user that someone else has made changes to the record, and ask if the changes should be overwritten. Has worked so far- and even in heavier traffic apps, this almost NEVER happens.