Oh, OK, I see what you're saying... The SYS(3055) does work for you, but you're just wondering why you even need it because the help file states that it is only essentially needed if you don't have a key field list, right?

Well, the help file for TABLEUPDATE() is actually wrong, or perhaps just incomplete.

It really has to do with the way your view is set up. In the View Designer, look at the "Update Criteria" tab for your view. And look at the section that says "SQL WHERE clause includes". The option that's selected is probably the VFP default, which is "Key and Modified Fields". This means that when you do the TABLEUPDATE(), the WHERE clause that is created behind the scenes by VFP is a potentially long one, because, according to the help file (for the View Designer), this option "Sets the WHERE clause to detect a conflict if the key field or one of the modified fields in the record in the original table has changed since the view was first retrieved (default)." So if you modified a bunch of fields, the WHERE clause can be quite long.

If you change the option to just "Key Fields Only", then the WHERE clause will be simple, only constructed with the key fields. However, you run into the potential problems of another user changing the same fields you're changing between the time the you retrieved the data and the time you did your TABLEUPDATE(). In other words, you won't be able to trap an Error 1585 or 1494 (which essentially state that there's a conflict and that the record has been modified by another user).

So it depends on what your needs are in your particular application. Since you can use the SYS(3055) option to get around the 40-field limit, take advantage of it. In earlier versions of VFP, this SYS(3055) wasn't available to us, and the limit back then was only 23 crummy fields.

Hope this helps explain things.

--Brad