>>>>I'm updating a view (buffering=5), even go top, the TABLEUPDATE(2,.T.) returns .t., but trying to change buffering results in an error.
>>>>
>>>>What am I doing wrong, or how do I get it right?
>>>
>>>Check the return value of TABLEUPDATE, if it returns .F., use AERROR to see why.
>>>
>>>If it returns true, but it appears that some records were not updated, I would guess you have a problem with primary keys?
>>
>>Right you are, it's the PK.
>>Now the question remains, what's the fastest way to find the offending record(s)?
>>
>
>You shouldn't have to go through all that to find duplicate PKs. Your base table should have a constraint on its PK so that duplicates are not allowed at all.
>
>PS, the code you posted never does a GO to the next modifies record.

I thought so too, but apparantly TABLEUPDATE(1) does that, or it seems implied in the code that Mark posted 27/04/2001 10:36:35, and from what I can see it works.

The reasoning behind the code I posted in my reply to you is the following:
First try to update the whole table. If that fails, find the first record that failed and retry the update for this record. If that fails, revert this record.
This may have been the only record in the table that could not be updated, so try to update the rest of the table in one go. If that does not work, start over.
If this is lousy thinking, please let me know.

As to the base table having a constraint, I'm not sure I understand, rephrase that: in fact I'm sure I don't understand.

The PK is the constraint, isn't it? SQL Server does not allow duplicate primary key values, and rightly so.

But the server-side base table doesn't know about the key violation before the TABLEUPDATE(2,.t.), right?

Now I'm pretty new to SQL passthrough and C/S computing, and I'm wondering if I have got the whole thing wrong?