Brian,
IMHO
I beleive that TABLEUPDATE( .T.) works fine when you have CURSETPROP('Buffering' , 3 ) but you need the additional parameters in TABLEUPDATE() when CURSORSETPROP(Buffering', 5) otherwise you only update the current row and the buffer contains uncommitted data, which is where this thread started I think.

>Andrew,
>Believe me, I tried every possible combination of the TABLEUPDATE() before realizing the buffer modes worked backwards. For starters, TABLEUPDATE(.T.) *does* commit all rows to the server! VFP simply doesn't recognize the changes have been committed. TABLEUPDATE(1,.T.) worked the same, no difference at all. Using the lForce parameter has helped in some instances, but not this one. It wasn't until I switched the buffering mode to Optimistic Row, CURSORSETPROP('Buffering',3) that I got Table Buffering to work, using both VFP5, and VFP6, with SQL7 and the latest MSSQL ODBC driver.
>
>
>>Hi Brian,
>>I hope I am not jumping in here where angels fear to tred, but -
>>Tableupdate(.t.) mentioned in your post will only update 1 row and if you have cursorsetprop('buffering',5) - voila -> the is your error.
>>The tableupdate function needs the nrows argument set to 1 or 2
>>tableupdate(1, .T. ,'mytablealias')
>>Also the setting of MULTILOCKS gets involved.
>>Maybe John's action of using an earlier version of his form is also a clue. With the Form | Data | Buffermode set to 2 - Table Optomistic, then what you get is buffermode 3 for normal controls and 5 for grids. However it also depends on the BufferModeOverride in the DE for that table which may have been 5 on the problem form and 1 ( use form setting ) on the earlier form.
>>Thanks for this thread, I found a potential problem on one of my forms that was waiting to bite me.
>>My new years resolution is to use a lot more of cursorgetprop()
>>
>>