>If I remember correctly, in FPW 2.6, I had to do somewhat a little coding on that to see if the data was changed, but that was in 2.6 days. What am I overlooking at this point? The error message is what the title says.
>
>Chuck

Chuck,

Let me tell you what approach I use in such cases. But I'll start with a some background:

Suppose I have one app divided in more modules. All the modules deals with the same main table. Suppose one user downloads one record to edit the name, and another user download the same record to edit the social security number (there are pure examples - you'll adapt this for your special case).

More than that: suppose the name and the number are edited from different modules, and the users don't see one each other's fields.

Let me give some data: suppose the name is JOHN DOE and the number is 12345.

- At time 0: In the base table (VFP or SQL - it doesn't matter) name = JOHN DOE and number = 12345.

- At time 1: Both users download the same record, without knowing one about another.

- At time 2: First user edit the name and he have now: name = JOHN SMITH and number 12345. He save the record.

- At time 3: The second user edit the number and he have now: name = JOHN DOE and number: 987654321.

When the second user save his local edits, he'll overwrite the first user's edit, *without being aware of that*. He doesn't even know he had the name in local view or something.

So, the solution with TABLEREVERT() and edit again is very annoying and very frustrating: "Why the hell should *I* edit the record again? I didn't did anything wrong! The app is wrong! Why should I be aware and why should I know how the data is organised inside? Simply I don't care! I didn't edited the name!" -- I'm pretty sure you know what one should think in such cases.


---------------------------------------------------------------------------


Backgound over. Let me tell you what *I* do in such cases. Your mileage may vary. This is only my solution:

I don't use TABLEUPDATE() directly. I've created a class which receive the table name as parameter.

There are some very useful functions: OLDVAL(), CURVAL() and GETFLDSTATE().

GETFLDSTATE(-1) will return a string consisting in your case only in 1 and 2, where first letter is the deletion status, and the rest are fields edited. If a field was edited, it has 2.

So, in the above case, the second user will have 112 as result for GETFLDSTATE(-1). There are three cases:

1. In the base table were modified only fields which haven't been modified here. So I uncoditionally download them and make the updates locally, without informing the local user about this. He doesn't need to know. When he saves his edits, it will save in fact name = JOHN SMITH (I've updated silently that field) and number = 987654321

2. In the base table weren't modified any fields. Everything should be ok. TABLEUPDATE().

3. In the base table were modified fields for which GETFLDSTATE(-1) returns 2 - so the local user has modified those fields, either. In this case I show a messagebox which displays the old value (OLDVAL()), the new value from the base table and the current value (CURVAL). Then I ask the user what to do. It's a standard way to solve the update conflicts.

-----------------------------------------------------------------

If you want, I can mail to you the class, so you can study it. What do you say?


Hope this helps.