Ian,

I'm not sure what your complaint with the docs is. The purpose of TABLEUPDATE() is indeed to commit buffered changes. The docs do state that it returns .F. if the changes weren't commited.

Nancy's right that you'll save time by not selecting the work area. You have to use all three TABLEUPDATE() parameters to do this and the alias is a character expression so you need to put it in quotes: TABLEUPDATE(1,.F.,'myalias'). You can also use the alias in TABLEREVERT(): TABLEREVERT(.T., 'myalias').

Unfortunately you do have to check the return value of TABLEUPDATE() every time. This is a little more work, but it offers a lot more flexibility. You can use different strategies for handling update conflicts under different situations. It also allows you to roll-back an entire transaction if the user chooses not to commit changes to a single table.


>Thanx big time Josh & Nancy!
>
>I had done about an hour of testing earlier on but had apparently 'by the grace of God' been doing my SKIP's at the 'right' places which meant my routine worked. I was about ready to lose it!
>
>Anyway, I have tested a your suggestions and they work fine, for two issues:
>1: Whoever wrote the docs for TABLEUPDATE needs to be @#$@#$. Here is an excerpt
> a) VFP Doc Definition=COMMITS changes made to a buffered row
> (i.e. nothing about testing in the word COMMITS)
> b) VFP Doc Example starts with: The following example demonstrates how you can use TABLEUPDATE( ) to commit changes made to a buffered table.
>
>2: I can't beleive that I am going to have to do:
>SELECT dm_operator_partners
>IF TABLEUPDATE()=.f.
> DO updateviolation
>ENDIF
>SELECT dm_request_lines
>IF TABLEUPDATE()=.f.
> DO updateviolation
>ENDIF
>...
>
>everytime, to get my:
>
> ask=MESSAGEBOX(error_message+" in "+alias()+Chr(13)+chr(13)+;
> "Someone else modified the same record at the same time"+chr(13)+;
> "as you in table."+chr(13)+chr(13)+;
> "You now have two choices:"+chr(13)+;
> " OK = OVERWRITE THEIR changes, or;"+chr(13)+;
> " CANCEL = To UNDO YOUR changes.", 1+48+256, "ERROR: UPDATE VIOLATION")
> IF ask = 1
> TABLEUPDATE(.t.,.t.)
> ELSE
> TABLEREVERT(.t.)
> ENDIF
>
>procedure to function. What a load of extra code!
>
>Nancy: P.S. In this case, using the Alias in the argument in TABLEUPDATE will not function because TABLEREVERT has to have the table with the prob SELECTED. But for future reference, I did try TABLEUPDATE(.T.,MYTABLE) and I got CAN NOT FIND ALIAS 'MYTABLE'. Yet code SELECT MYTABLE and then TABLEUPDATE(.T.) works just fine. The alias name has not been altered in anyway and the alias name appears correctly in my UPDATEVIOLATION procedure. This is nothing to spend time on but I if you have a quick idea why this did not work, I would appreciate reading it.
>
>Sorry for the long windedness... This problem almost sent me over the edge! I have to go but I will check responses in an hour or so.
>
>
>>In addition to what Josh posted...you should be checking the return value of TABLEUPDATE in case it fails. Also, if use the alias parameter of tableupdate then you don't need to select (takes time to select a work area, saves code, too).
>>
>>Just my .02 US
>>
>>>On tables that have OPT ROW BUFFERING (i.e. #3 set in DATA ENVIRONMENT), should TABLEUPDATE(.T.) cause an error when when two users have changed data in the same table at the same time. 'Cause I thought it was supposed to!
>>>
>>>I have several tables open at once on a given form. Before my SKIP+1 code I have:
>>>
>>>< SELECT A
>>>< TABLEUPDATE(.T.)
>>...snip