...and to add to that, it only crashes when it is run with the INTO clause set to a particular view. In the command window if I substitute another name (vTemp instead of vDetail) it works. The other way around it does not...

Renoir

>Double "Hmmmmm..."
>
>The full expanded SQL works from the command window, but not using the Requery. Any thoughts anyone?
>
>Renoir
>
>>The Where clause uses just the key fields and is only 88 in length. I guess I'll pull the SQL out to the command window and start playing with it. I'm thinking of removing all the alias portions (LastName instead of vEmployee.LastName). If I get it to work, is there an easy way to incorporate it back into my database. I guess I'll lose the view designer functionality if I go this route...
>>
>>Renoir
>>
>>>Hi!
>>>
>>>Possible cause also:
>>>When you have pending changes in the view, requery() does try to update daa automatically. When SQL Where clause is too long, you will receive this message too. Change options in view designer to include only key fields in the SQL Where clause.
>>>
>>>Havo no other ideas, maybe someone else jump in...
>>>
>>>HTH.
>>>
>>>>Hi Vlad,
>>>>
>>>>Just what I was looking for... The total character count for the expanded SQL was 1,715 so I'm not sure why it is failing.
>>>>
>>>>Renoir
>>>>
>>>>>CursorGetProp("SQL")
>>>>>
>>>>>However, if you have a parameter like "&?lcWhere" and lcWhere contains too long string - here is a problem. SQL Statement in VFP could not be longer than the command line limit (~8000 characters) after expanding of all macros.
>>>>>
>>>>>There are several ways to make SQL Statement shorter...
>>>>>
>>>>>>I'm getting an "SQL statement too long" error during Requery of a view. While in debug mode can I view the actual SQL being used to generate the view? I know I can see the original code in the view designer, but what about during execution? Thanks!
>>>>>>
>>>>>>Regards, Renoir