Thanks, Markus. I worked around it for now. I already had WhereType=1, but it didn't help.

The problem was I this: Before updating I did a SCATTER and then a GATHER, and (after testing I discovered that) this causes the FldState for ALL fields to be set to 2=modified. So VFP tried to send all fields in the SQL Update statement. Here's my workaround: a little program I called FixFldState.

for lnN = 1 to fcount()
   if evaluate(field(lnN)) = oldval(field(lnN))
      *** Nothing changed.  Reset field state
      setfldstate(lnN, 1)
   endif
endfor

The result is that only the fields that are truly modified are sent. That's OK for modifications, but for new records I suppose I could still surpass the 128 field limit. Maybe I need to rethink my data base structure. Hmmm.

----------------------
>Hi Tom
>
>I'm not that sure if the error you get is "correctable" by SYS(3055).
>
>The error reads in the help (Sorry, I have to translate this from german ;) )
>
>"You tried to use SQL-Update with more than 128 fields to update"
>
>Even if I don't know about that limitation, it makes me thinking. I must admit, until now I never have had a table with 128 fields. So if your field count is really that high this might be a different problem.
>
>To exclude the where clause issue you are aiming on with SYS(3055), you can try to alter your view definition in a way that only the keyfield(s) get into the where clause and not all of the updatable fields, that should clear that problem immediatly.
>

> =CURSORSETPROP('WhereType',1,'YourView')
>

>would do that.
>
>HTH
>Markus
>
------------------------
>>I have a VFP local view (built off a VFP remote view, but I don't think that matters). When I try to update I get Error 1864, "SQL: Too many fields in update". Sys(3055) doesn't seem to help. Any suggestions?