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()


>Hi John, we've just been over the same issue, which popped up when we upgraded to VFP 6, running a C/S environment with the new SQL Server7 as back end. SQL7 is fantastic, BTW. But you're not gonna believe (?) what the problem/solution is.
>
>I didn't get the specifics of your app. We are running VFP Remote Views, and doing most of the inserts and updates, on the largest table (2 million rows) with TABLEUPDATE(). It's been working great in VFP5 with SQL 65. However we began getting the Uncommitted Changes error you describe, as soon as we upgraded both VFP and SQL together.
>
>For starters, the VFP View Designer's default behaviour needs tweaking. In the Update Criteria panel, when you click Update All, it doesn't update all. It doesn't update the most important fields, which are the Primary Keys for your table. You must manually click those fields. Doing this will add those Primary Key fields to reflect in CURSORGETPROP("UpdatableFieldList"). Or you may programmatically add them with CURSORSETPROP("UpdatableFieldList").
>
>Now, the other default is CURSORSETPROP("Buffering") =3, for Optimistic Row Buffering. I am doing lots of multiple row updates to the cursor with say, 10 to 50 rows at a time, back into the 2M backend table. So of course, I've got Optimistic Table Buffering enabled. You didn't say whether you had Table Buffering enabled, or not.
>
>Here's the catch with my situation. Table Buffering no longer works with SQL7 or perhaps the newest SQL ODBC driver. Are you ready? get this -- if you set the Remote View to CURSORSETPROP(Buffering) =5, Table Buffering, it behaves like Row Buffering. And, if you enable Row Buffering, you guessed it -- the View now updates all rows and commits changes to the back end server, no problem, absolutely. With Table Buffering enabled, the changes ARE committed! However the VFP View doesn't recognize it, you can verify with GETFLDSTATE(-1) for subsequent rows. It acts like only 1 row is committed. Then when you REQUERY(), of course you get the error. Tableupdate(.T.) still returns .T. because the changes WERE committed. However the Buffering mode in the View doesn't reflect committed changes. To put it simply, the Buffering properties of VFP Views are switched backwards.
>
>I'm working with MS Support on this. True, the error could be in how the ODBC driver returns the committed changes to VFP, but likely it's how VFP is translating the message from ODBC.
>
>Brian Lee
>World Access Network, Inc.
>
>>Thanks everyone for his/her suggestions to my problem.
>>
>>The Good News: I'm relieved to inform all of you that the problem have been solved.
>>The Bad News: I don't know exactly what was wrong in the first place.
>>
>>I tinkered with it (e.g. commenting out pieces of code here and there) this morning and all of a sudden it started working. What's more weird is, I'm now trying to duplicate the problem again so that I could find out exactly what went wrong and I can't! Originally, I though I trace the problem to multiple TABLEUPDATE() calls with latter calls that involved no data changes (although the error was generated from first TABLEUPDATE call) but I could do this now w/o any errors. I've copied over a same form from backup that wasn't working and now it works perfectly. This tells me the problem was view related and not codes within the form. Maybe I should just be happy it now works and move on but I just got to find out why.
>>
>>
>>>John:
>>>
>>>Have you tried to use the GENDBC or similar utility to get the code VFP is using to create the view and set the field update properties? If you can get a look at this code you may be able to find the problem easier. If nothing else, you could use the code, tweak it if necessary, delete then recreate the view programmatically including all the updating properties.