Yes, well, perhaps some parts of the help file are confusing in this case.

But I think it is quite clear that when you select "Primary key only" (in the option, "sql where clause includes", under "updates"), for the updates, VFP will internally generate a SQL statement that is simple... and dangerous, because you lose conflict control.

And when you select "All fields", or the default (preferably, I think), "Key and modified fields", VFP will generate a more complicated SQL statement, and that is where your SQL statement can get too long.

BTW, I still think that when you have data for different months, or years, in different columns, the data is not exactly normalized, that is, according to the five standard normalization rules. However, I will not insist that strict normalization is desirable or practical in all cases. It is convenient in most cases, but I myself have used exceptions in some cases.

>Thanks a lot Hilmar.
>
>What I don't understand is that I have surrogate primary keys for all my tables, and I indicate them to be the one who drive the updates in views.
>It seems as if the SQL WHERE clause depends on how many fields you have to update, but the SYS(3055) function only talks about not having a primary key.
>
>>I think I finally got a solution from the friends in the dfpug.
>>
>>Without having to change anything in the view, or doing some complicated checks, you can change the value of sys(3055)
>>
>>HTH,
>>
>>Hilmar.
>>
>>>Hi all,
>>>
>>>I have a view in a form that updates a table with 100 fields. The SQL statement is short, as all the fields belong to one table but 2 of them.
>>>
>>>When I issue tableUpdate(.t., .f., 'myView'), I get the error "SQL string is too long", and return .F.
>>>If I force all rows to be updated with tableUpdate(.t., .t., 'myView'), then I don't get the error.
>>>
>>>I don't even know how to debug it to know what's happening inside, and why the error goes away when I force the update.
>>>
>>>Any ideas?
>>>
>>>TIA,
>>>Javier.