>>To verify that this is in fact the problem, you could try creating a temporary cursor that matched the view on a field for field basis; if you can GATHER NAME into that, but not into your view, that's what's happening. As far as a workaround, you could try spinning through the list of fields one by one in a FOR loop and doing REPLACEs; something like:
>>
>>

SELECT MyComplexView
>>FOR i = 1 TO FCOUNT()
>>   REPLACE (FIELD(i)) WITH EVAL('oMyScatterObject.' + FIELD(i))
>>ENDFOR
>>

>>
>>>If I try to REPLACE just a few view fields from the parameter object, it works. If I try a REPLACE of all, or slightly more than half, same error.
>>>
>>>When the modal form is closed, the .Activate of the view form is eventually called, which refreshes the view form. The error handler is reporting the problem in a piece of code that works perfectly in every other circumstance and which contains no SELECT - SQL statements even approaching the limit.
>>>
>>>The view-based form is fairly complex. Has VFP been known to throw bad/misleading error messages when the going gets tough?
>>>
>>>Any help or wild-assed guesses greatly appreciated.
>
>Ed, thanks for the heads-up regarding GATHER NAME. I implemented your code sample, which works fine. However, another problem has come up which is probably the root cause.
>
>I put a WAIT WINDOW "REPLACEs Complete !" command immediately after the FOR loop, in a custom method of the calling form. When I return from the called form, the FOR loop runs and the WAIT WINDOW shows up. Get this, though - VFP does NOT stop at the WAIT WINDOW - it keeps rolling along right through it. Since I'm using the VFE 5 framework, it effectively does a form refresh. I don't know whether this is some sort of pseudo multi-threaded behaviour or what but it doesn't look kosher.

I have no clue - I don't use VFE. A modal event in a modal form should bring things to a halt AFAIK.