Thoughts about Query application

From: NN
Keywords: Querier, EmailNotify, Suggestion
Remote Name: 63.22.117.205
Remote User:
Date: 01/25/01
Time: 21:20

Comments

Mike,

I'm sending this as plain e-mail and also repeat in the Query forum.

Mike designed generic utility called Querier, which basically could be used in any environment.

In order to use this generic Quierier class in JobControl Nancy wrote a wrapper application, called Query. The purpose of this layer is to provide a communication between Quierier and Job Control module. In Query wrapper Nancy executes some special code, which is relevant to Job Control module.

Now, there are situations, when some code should be executed in time of Querier running its QueryCommand method. In particular, some code executes just before these lines: * invoke output generation - multi-line, macro-expanded SELECT statement &selectcmd1 ; &selectcmd2 ; &nextdest The code, which precedes these lines, is indicated with NSL comments, it places selectcmd1+' '+selectcmd2+' '+nextdest and qry_usrparm along with JobID into ViewSQL table, if Query runs in Show SQL optimization option turned on.

Immediately after these lines there is another inclusion, which writes additional info into ViewSQL table and PerfLog table.

Now, the question is: how make these inclusions as minimal as possible to not "pollute" the generic class with specific JobControl things.

It seems to me, that I came up to some idea here.

First, let's find out, which Query attributes are interesting for JobControl module. They are: 1)QuerySQLString=selectcmd1+' '+selectcmd2+' '+nextdest 2) qry_usrparm 3) Query Elapsed Time 4) Query Number of records

Also, Query could be executed in two modes: with Show Rushmore optimization and save it into file and without showing it.

Now, how make these properties available for Query wrapper? Very easily: make them to be properties of Querier. You can also make an Assign method of these properties to execute Parent Class (Query wrapper) some method, but this may become unnecessary.

Also monitoring Rushmore optimization and placing it into some file could be a native Quierier feature (could be a flag property in Querier, which would tell to monitor it).

This way there is no need to include code directly into Querier class and therefore Quierier class could be maintained independently on the parent wrapper class.

Now, I have some additional thoughts regarding Query Wrapper. I think, instead of using random generated name for Clone Function_ID, we may use 4 (or 3) first letters of Template FunctionID (excluding first * symbol) +JobID. This way each cloned template could be easily associated with its Job Record and also there would not be a chance for duplicates (since JobID is a unique identifier), so checking for uniqueness or opening BtCrit MetaFile would become unnecessary, so the code would be simplified.

These are ideas, if you're interested, I may give my thoughts in more details.

I have also ideas regarding integration of Error Handler & XForm and Error Handler & Query, which I discuss in appropriate forum (Error Handler).

Thanks in advance.

Brought to you by SpaceTime Systems.  All rights reserved.