|
| Discussion | |
From: mda
Keywords: Querier
Remote Name: 24.218.251.162
Remote User:
Date: 10/09/01
Time: 22:34
I've just completed a couple of long-standing Querier tasks:
These changes bring the current implementation of Querier up-to-date in its support of the latest ErrHandler features, as currently used by XformDBF and BTCrit. I also took this opportunity to adjust some naming conventions for greater consistency, but I've retained support of obsolete method and macro names for compatibility, until these have been entirely phased out. Please substitute new method name QryM_Run for QueryCommand, so I can eliminate this obsolete method. Also see querier.h for new error code and message macros, which should be substituted for any references to the old macro names (listed at the bottom of this include file). Be sure to use macros, not hard-wired Querier error numbers, because these have been redefined. If you are using the old macros, it will suffice to rebuild with the latest querier.h include file, but please let me know when all references to obsolete macros have been eliminated, so I can discard the extra compatibility cruft.
The effect of these changes can be seen in various Querier failure cases. Previously, many types of predictable user errors (such as invalid expressions in Querier metafile fields) were handled as "exceptional" errors, a catch-all category intended for unforeseen program errors. Now such predictable errors are handled more gracefully, with more informative error messages and cleaner, more consistent failure logic.
The demo wrapper program, querier.prg, has been changed to force enablement of the diagnostic error message dialog by default. This means that instead producing error messages via WAIT WINDOW, the demo automatically uses the more useful ErrHandler dialog. (You can revert to non-diagnostic mode by simply un-checking the Diagnostic Mode and Diag Force options via the diagnostic message dialog.)
For example, if you go into the Querier development directory and issue this VFP command line:
? querier( )
you will be running the default sample query, which starts with a dialog prompting you to select a query destination. If you click on this dialog's Cancel button, you will then see a diagnostic message dialog for Querier Error # 56, with the message:
User Escaped or cancelled from output destination dialog.
Query Id = demogen01
Previously, this sequence of steps would have displayed the error message via WAIT WINDOW NOWAIT, and it would have been more difficult to get to the diagnostic message dialog.
To see an illustration of the new Querier diagnostic features, try using the diagnostic dialog to set the Trace Level to 11. (This value is defined in querier.h as macro QUER_TRACE_ALL.) With the Trace Level set to 11, run any of the sample queries, and a diagnostic tracing message will be displayed after each query execution. This tracing message shows all of the new Querier diagnostic properties, including elapsed query time and expanded components of the SELECT statement just executed. All of the standard ErrHandler output echoing and logging options are supported for this diagnostic tracing message, as for any error messages.
The sample query definitions metafile includes some illustrations of how to connect Querier to BTCrit, via the usrparmexp expression. Since BTCrit has been updated since these examples were last tested, it will be necessary to update the sample BTCrit configurations before these test cases can be used. I have no reason to expect that this will be a problem, but it should also be noted that a further refinement is called for in order to correctly propagate any BTCrit error information back to Querier.
The scheme I have in mind (not yet tested) boils down to something like this. Rather than constructing a usrparmexp like:
btcrit('run', 'btconfig01')
Use this form instead:
btcrit('run', 'btconfig01', .f., m.qry_querier)
In other words, pass the Querier's own object reference to BTCrit's targobj argument, employing target indirection to copy BTCrit's error information directly into the Querier object. This should ensure that Querier returns BTCrit's error information if BTCrit encounters an error.
There are now several clean ways to log Querier's diagnostic information, without resorting to any alteration of the core Querier class code. You have the following options for logging query diagnostics:
Also note the possible addition of Rushmore optimization information to the available Querier diagnostic properties, but this feature has not yet been implemented. In the meantime, capturing and logging of Rushmore info could be handled in a customized wrapper function, or simply by issuing SYS(3054, 11) from VFP command level if screen output will suffice.
|
|
|
|
| Contents | Discussion | |
|