>Erik,
>
>>When setting up complex updateable views, it woud be helpful to be able to see the SQL that VFP constructs and uses when building a query for REQUERY and TABLEUPDATE. I know that this SQL exists, because freaky occurences have put the strings in my AERRROR() fields before and showed up in my error log.
>
>>It would be nice to have a command like:
>
>>SET SQLOUTPUT TO c:\sqllog.txt
>>SET SQLOUTPUT ON
>
>>that would echo all of this SQL to a file.
>
>Well, this sounds nice.. but what advantages does it give ?? Determining where the error messages come from ?? Maybe then it's a good idea to advance the aError function. Maybe it's a better idea to have more control over how the REQUERY and TABLEUPDATE internally works.
>
>Walter,

We have almost ultimate control over how REQUERY and TABLEUPDATE work. It lies in the view definition. But sometimes there are settings that affect the SQL that aren't totally obvious and are difficult to see even with eView.

Extending AERROR would be nice, but not as powerful as seeing the SQL- because it would only work when the view caused an error, or a TABLEUPDATE returns .F., and not all view update and query problems cause errors, they just behave differently than expected.