Active list is ignored in VERBTIMER program

[wags]

I love the concept of the VERBTIMER program, and have implemented a version of my own. However, there is currently a nasty bug that comes along with this. If you have an active select list going into this program, it is ignored. The new SELECT that happens within the program gives you a brand new list based on the most recent criteria, rather than a derivative of the list you previously had.

It is pretty easy to recreate the bug.

1. Follow the README to get everything set up.
2. Do a SELECT at TCL with some specific criteria or perform a GET.LIST.
3. Immediately perform a basic SELECT, like SELECT <Filename>.
4. You will be left with a list of all records in that file, rather than the previously selected records.

Is there a way to respect any previous active list? I need this to be 100% transparent to the user for it to have any chance of running in production.

/cc @byrnem

[wjhonson]

Would this not be a case where the program needs to check at the first executable line, whether or not there is an active select list currently, and if so, to save it off, or do something else to preserve it.

[wags]

Hi @wjhonson! Yes, I agree with you that some kind of active-list detection might help. Using SYSTEM(11) in the program can detect if select list 0 is active. (Returns 1 if select list 0 is active
and 0 if it is not.)

The problem is that I want to use that previously-active list and filter it further using some other criteria. This is often the case if the list was obtained with a GET.LIST command. We strategically create saved lists and then use them as a starting point throughout the day/week for performance reasons. The EXECUTE statement in this program starts over every time and ignores any stacking/filtering that may have already taken place. Currently, I don't know of a way to make it behave any differently.

[wjhonson]

Well if you detect the active list, can you then execute a save-list or something would that work?
Or can you loop a readnext and save it off to an internal array?

[wags]

Something like that could be done, but I think it would require more predictable usage of the program in order to be successful. The goal is to avoid tampering with the SELECT functionality at all. It would be awesome to be able to stealthily capture some performance metrics without affecting functionality. Remember, this is a wrapper around the native SELECT verb, used at TCL. I want to look for inefficient queries based on how long they take to complete, but I have no way of predicting what kind of sequence of queries my users will come up with.

Because the actual SELECT verb is being swapped out in the VOC, this wrapper program runs for all select queries. In order to actually use it, I can't have it breaking normal, expected TCL functionality.

Here's some sample terminal output to highlight the problem:

>SELECT USERS

314 record(s) selected to SELECT list #0.
>>SELECT USERS WITH FIRST.NAME = "Matt]"

7 record(s) selected to SELECT list #0.
>>SELECT USERS WITH LAST.NAME

314 record(s) selected to SELECT list #0.
>>

At the end there, I would expect to have 7 records in list 0, not 314.