| Discussion |
Keywords: Querier, Enhancement, Suggestion
Remote Name: 188.8.131.52
I like your idea about adding some Querier properties to make it easy to capture additional information cleanly. I believe that the qryp_tally property, which already exists, covers the record count, but the additional properties you mentioned (expanded query string components and elapsed time), seem very sensible.
Also I agree that it makes perfect sense to add a Querier toggle for displaying Rushmore optimization info, i.e. making use of VFP's sys(3054). I'm not yet sure about the best way to capture and/or display the Rushmore info, but that's a detail we can iron out, presumably with some input from Nancy too.
Since I'm about to make a Querier update (for recent ErrHandler changes) and additional changes are anticipated (e.g. quma0002, old tasks listed in querier.txt, etc.), I would also agree that it makes sense to avoid the need for any else's making direct changes to the Querier programs, which obviously carry certain risks, require redundant maintenance, and create compatibility problems. At the same time, I understand how the present, hopefully temporary, situation came about. Let's just agree that this is something that should be fixed, but it's not yet clear when. All of these Querier improvements will probably have to wait until Alan decides to bump their priority. At some point soon I'll create some expanded task descriptions, including your excellent suggestions, to help us pursue this further.
It sounds as though you haven't quite settled on the best conventions for BTCrit functionids, but I think you're on the right track. This is really more of a Saver issue than a Querier issue, so we should redirect discussion about BTCrit functionids to the Saver forum. In my previous reply to Nancy on 1/17, I suggested avoiding increasing the functionid width if it isn't necessary to do so. Just let me note here, however, that you shouldn't be overly discouraged from increasing this width if it makes a big difference to Nancy.