I can see the sense in that, almost. Indeed, since I uploaded the message, I've gone back to trying it that way (getting my own key values) and it works fine. But in that case, whats the point of having the wondrous DBC file which is supposed to take care of that sort of thing. IT knows what the next value should be because it stores it in the "next value" field in the Table Design data, AND its correctly incrementing the damn thing!

Ach well, if it can't be done, it can't be done. At least you've stopped me banging my head against it.

Thanks



>The problem is that remote view "doesn't know" the next integer id, and probably the default value is 0. If you want to add recods to view, you must know the next id before you add the record. The old method is better in this case - default value = getkey('{table_name}').
>

>>
>>If I experiment with permutations of key arrangements I get the following errors from Tableupdate() after I try to Save:
>>
>>With the key I want to use - an Autoincrementing integer - I get "Uniqueness violated" (1884).
>>(despite the fact that the autoincrement counter is correctly incrementing: Its as though the tableupdate is attempting to insert the new record before the counter is incremented, fails, and Then increments the counter)
>>
>>If I switch off the unique requirement in the index, the failure is "Record is not locked (130)" (on a standalone workstation).
>>
>>If I add a similar key to the table whose views are updating correctly I experience similar errors with updating new records, with the addition of "Record is in Use (1502)".
>>
>>I have allowed the default buffering which is level 3 (optimistic Row)
>>
>>Codewise, I'm using the txtbutton class that comes with vfp 8. Its "updaterows" method traps the errors. The only amendment I've made to the code is to add a few more defined error conditions so I can see whats happening in real time.
>>
>>Suggestions?