Thanks Vlad

This weekend I came to that conclusion. I reeeeaaaalllllyyyyy appreciate confirmation of my thoughts. I work in a, "I am the only one here" vacumn and never know if I am truely taking the "best" approach to a problem fix. I am going to use the EditMode to turn on and off the Requery function in my grid refresh method. That should solve my uncommited message. I will then do an imediate tableupdate for Add & Deletes and force the user to delete any adds that they didn't intend rather than trying to get the revert button to handle it. In my reading I was left with the impression that Views worked too closely to the same way that tables did. I thought ALL changes were buffered and therefore were revertable at any time. I see now that when using a parameterized view you have to be very carefull of moving the record pointer with a Requery as that seems to force some sort of attempt at cleaning up the source & buffers.

I will take a look at the threads on tableupdate. I was under the impression that Barbara was saying that my syntax of TABLEUPDATE(.T.,.T.,"XXXX") was old and was asking if there was a better syntax for it.

Thanks so much again

Terry

>Hi!
>
> 'uncommited' changes error you get each time you tru to requery data or do something with indexing. I see no problems with that, for example, disable any requery when user changed something or disable any sorting. Usually, UI contains such thing as 'edit mode', which switched on automatically when user start to change something. When form switches to edit mode, usually it disables certain functionality (buttons, selectores etc.) that cause conflicts when changed data not saved. It looks like that is what is needed for you form.
> About tableupdate is obsolete: Its tru and not true. Its depended on the architecture of your application (n-tire - not n-tire), methods of data manipulation (VFP cursors, views, tables, ADO recordsets, VFP data objects etc.) and data backend (SQL server/ODBC or VFP file server). If you do not change application architecture, no need to replace tableupdate() by something else. Note that VFP don't have other commands for quick and reliable updating of view/cursor, however, UPDATE command might help sometimes.
> There are also many threads here discussed the best ways of data updating using tableupdate, auto number fields for new records, OldVal()/CurVal()/GetFldState()/GetNextModified functions etc.
>
>>I put a thread on last week asking about uncommitted changes using a parameterized view.
>>
>>I use the view as the source for a grid and in the refresh method of the grid set the parameter and issue a requrey. This works perfectly untill changes are made to the information in the grid. If I don't emediatly TABLEUPDATE before the refresh/requery gets issued I get the 'uncommited' changes error.
>>
>>I like the buffer modes offered by VFP and want to allow the user to make changes to their data with the ability to revert or save at their discression.
>>
>>Am I missing some philisofical point or what?
>>
>>Also, it was pointed out to me that TABLEUPDATE(.T.,.T.,"Xxxxx") was obsolete coding practice. Can anyone update me as to how it is done now?
>>
>>Thanks in advance
>>
>>Terry