>This is what's going on: when you check "Key and updatable fields" in the view designer, the SQL statement includes all fields in the WHERE clause to check for conflicts with other users. That means a long SQL statement.
>
>When checking "Key fields only", then SQL only includes a few (or one) field in the WHERE clause to check for conflicts with updates of other users.

Yes, that is what I thought.

>This is why I did not have the error when I used tableUpdate(.t., .t.), i.e. forcing all rows, as is almost the same as saying "Key fields only" (conflicts in the primary key are very, very rare).

Aha, I think I am beginning to understand. You mean that when VFP forces the update, it will not check if the fields were modified - and thus, generate a shorter statement.

I think that VFP will check its buffers (the ones accesible with oldval()) with the value on disk, before committing changes.

If you don't trust my opinion on this (and you shouldn't, when it comes to something as important as update conflicts), try the following: open the same form twice, and select the same record. Make changes in Form1, then in Form2. Save in Form1, then in Form2. If you don't force the update, you should not be able to save in the second form.

>What I loose using "Key fields only" is the automatic conflict management, which I can do elsewhere.

I don't think you lose conflict management if you use buffering. You will lose it, if you use forced updates - but that is quite a different issue.

> But at least the view is working, and I know why it is working know. Thanks a lot.
>
>Regards,
>Javier.
>
>>>Hi Hilmar, with your answer I have two more questions:
>>>- Is the SQL statement out of limits with 100 fields? I think VFP limit is of 8 KB per statement, which is a lot
>>>- Why does the error go out when I force all rows to be updated?
>>
>>I don't know the answers. But I still think that you should try "key fields only", to see if that works better.