Walter Meester
HoogkarspelNetherlands
Erik,
>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.
You are just purposing a feature like the SET COVERAGE command but for internal SQL handling by the REQUERY and TABLEUPDATE, don't you ? Maybe you can intergrate the two and let the SET COVERAGE option register all SQL activities (internal and external) like:
- Index use
- time needed to index matches (optimizable part)
- time needed to filter (non optimizable part)
- time needed for subqueries etc
This will enhance the profiling capabilities.
for example: SET COVERAGE TO file WITH SQLPLAN
Just thinking...
Walter,
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only