>Erik, I appreciate your help and input on this - SOMEDAY I'll get it straight.
>
>If 2 users are updating the same table, I'm trying to reflect changes that another user makes as soon as possible. I'm having trouble doing this...or at least testing it on my single computer, by running my app twice. First question is, should I be able to test TABLEUPDATE, REQUERY, etc. as it would operate on a network on this computer?

Yes. You should even be able to do it from the same app, as long as you have two private datasessions.

>
>If so, I'm having real trouble getting this straightened out.. I have a grid on a form and the control source is the updateable view. A user clicks on an Edit button and controls are displayed with the data (control source of controls are fields in the view). Ok, two users do this on the same record. One user saves their data first:
>
>IF !TableUpdate( 0, .F., "LV_AgenciesUpdate" ) && write changes - detect if someone else made a change
>...etc.
>
>When the second user tries to save their data, the TableUpdate() should fail, I want to display a message then refresh the grid with the changed data. Then the user can decide what to do about it. I'm having trouble displaying the change the other user made...

This should be no problem. But before we go any further you should be clear on the difference between Table and Row Buffering. Row buffering buffers ONE row at a time. IOW, if you have a row buffered view open, and you make changes to the first row, and then click on the next row in the grid, VFP does a TABLEUPDATE() for you. This is why I NEVER use row buffering. You have no control over when, and cannot read the return value from a TABLEUPDATE. IMHO, Row Buffering usually does nothing but make things a horrible mess. If one of the tableupdates fails, you don't know it (or you get an error), and you are left with a dirty buffer that should be reverted. What I just said above is basically what the Hacker's Guide was trying to tell you.

With Table Buffering, no changes are sent until you explicitly call TABLEUPDATE().

>Does the above imply the TABLEUPDATE() alone (by the first user) is NOT enough to be able to access the changed records by the other user (w/a REQUERY)?
>

No.

Code like you are trying should work, but let's now assume you are using Table Buffering instead of Row. User 1 opened a view, changed a record, and successfully committed the changes with TABLEUPDATE(). But Before User 1 saved the changes, user 2 opened the view and began making changes to the same record.
Now, when user 2 attempts a TABLEUPDATE with the second parameter as .F. (no force) it will fail, and AERROR will tell you that it was an update conflict.

I usually at this point ask the user what they want to do. If they say overwrite other changes with their own, then I do the same TABLEUPDATE, but with the second parameter as .T., indicating that the changes should be forced.

If the user says not to overwrite the changes, I do a TABLEREVERT(). If your first parameter in both functions was 0, either one of these actions will clean the buffer FOR THE CURRENT RECORD. If it was 1 or .T., it will clean the buffer for ALL records.

And this is where I think you were being thrown off. You were reverting changes to one record, and leaving a dirty buffer in another (it was still dirty because VFP's TABLEUPDATE() failed and didn't tell you).

Can you use this to work it out? If you can't tell, I'm a strong advocate of table instead of Row buffering. for the record, I also deal with updates and reverts for all records at once, to keep things simple. This means always specifying .T. as the first parrameter in both TABLEUPDATE and TABLEREVERT.