>>>>>Did you use it correctly? Check out Hacker's, you need to multiply the # fields by 8, it looks like sys(3055,400) for your case
>>>>
>>>>Yeah, I was doing it that way. I started with 8*fcount() and even went higher than that. This is getting annoying.
>>>
>>>I can imagine, sounds like the new sys() feature doesn't work. Does it update exactly 40? If so, then it sounds like sys(3055) isn't doing anything.
>>
>>Finally got it. The problem had nothing to do with SQL too long or SYS(3055). For some reason when I inserted a new record into the local view, the record was showing up in the base table immediately [no tableupdate was ever issued]. Well, in the base table, the default value for the KeyID field was firing and setting the KeyID value to the next integer value. Well the view still has the KeyID as 0 [I do not carry over the default value for the PK in the view].
>>
>>To work around this, I had to retrieve the next value for the KeyID and include this value in the Insert Into command so the view and the table would have the same KeyID value. Looks to me like the Create SQL View command needs a NoFilter clause option.
>
>I would be VERY surprised if I found that the view was using the base table behind the scenes. Could you verify this with DBF()? Is possibly the view row buffered and something is moving the record pointer without you knowing?

After further review, the explanation is much better. I stopped the debugger too soon. I have the VCR buttons that come with VFP on the form. The EnableDisableButtons method of this control moves the record pointer to determine which buttons to enable. This coupled with record buffering, was causing the problem. I was getting an implicit tableupdate issued which initialized the PK in the base table to its default value while leaving the PK in the view at 0.

Sometimes it helps to just walk away for the day and rely on [UT] voices of reason. Confidence restored. Thanks.