DROP ALL fails when no records have been selected (long)

[Barry Wiseman]

This browse lookup problem has been driving me crazy. 

>From an input screen, my program accepts low/high value ranges for each of
several fields, all of which are subfields of a compound index key in the
target file.  (This is an "old" index, built on one long field into which the
several subkey values are assembled.)

I then run a browse lookup, and my browse processing must validate that each of
the subfields is within range, otherwise DROP the record. I have initially
assembled a pair of compound keys consisting of lowest- and highest-possible
values in each subfield. My browse processing begins by testing against these;
if a compound key built from the record under test does not fall between them,
I issue a DROP ALL BEFORE or DROP ALL AFTER as appropriate. 

The problem is that, if there are no records at all that satisfy the search, the
DROP ALL is performed (as running with the debugger demonstrates), but has no
effect, i.e., the browse lookup continues to crank through all records to the
end of the file!

Here is a simplified piece of code that will demonstrate the problem.  It can
easily be adapted to any data you have laying about.  In this case, it is
looking for a range of invoice numbers for a given account key.  Try it first
with values in qq and qx such that some records will fall within that range; it
works like a champ.  Then alter the range so no matching records will be found. 
The MSGBOX will show you the browse lookup is reading through the entire file
despite having performed a DROP ALL. 

::end:
@KEYQ:::
::qq(20,*)="ZUPNICK    362429999":
::qx(20,*)="ZUPNICK    34051    ":
::zz="(brw=12 xkey=X prc=BPRC fill=desc,top)":
::zz=zz { "[Key         Invoice]*4          *3":
::lookup vtr = drvtrans  k=qq   i=A -nl b=(zz):
::end:
BPRC::qz=vtr(4)&vtr(3):
::msgbox qz:
:qz lt qx:drop all after; end:
:qz gt qq:drop all before; end:
::end:

I'm guessing the true meaning of the command is, "drop all records before/after
*the last record displayed in the browse lookup*, not before/after the record
currently being considered.  Thus, if NO records are selected, DROP ALL becomes
a no-op.  Grrr!!

If my actual program were this trivial, certainly MLEN= would be a better tool
than DROP ALL, however, in my case I cannot assume that the first subkey would
narrow things down that much. 

-- 
Barry Wiseman
Genesis Software Designs, Inc. 
55 W 45 Street, New York, NY 10036
(212) 889-9191    Fax: (212) 889-1589