Re: Missing numbers ( was Re: )

[Tom Liotta <qsrvbas@xxxxxxxxxxxx>]

Douglas Handy wrote:

> However, in this case I'm not sure why a lookahead would be any better than
> just reading the file and detecting when the record just read is not the
> next consecutive integer after the previous read.

Doug:

I'm not sure either. It was an obscure possibility that was only 
_potentially_ useful without me being clear on what the real 
requirements were. For only smallest available, its use is pretty 
much nil. For detecting a range of missing numbers, it might mostly 
just help automate the task of storing the previous key for the 
comparison.

> I'm with Joe here -- if there is a pre-existing index on the field that
> needs to be tested, a HLL program loop seems like a better tool for the job
> than SQL.  Given a number range, you just SETLL to the start of the range.
> If it is not in use, you already have the smallest missing number.  Then you
> just read the file by key, and the the first (or each) time the value is not
> one higher than the previous read, you found another gap.  Then you either
> quit if you only needed the smallest number, or continue until you have
> reached EOF or the high end of the number range requested.

Yeah, I agree. I'd maybe add that an actual READ op-code apparently 
isn't really needed as part of the execution, just to emphasize the 
key-checks are all that's needed. Given a known key structure that 
has a form [TX00001 to TX99999] where it can be numerically 
incremented in the digits portion, just the SETLL in a loop should 
be sufficient. When it doesn't get an exact match (not %found()), an 
empty slot was hit.

Beyond that, having a second table that lists all valid keys brings 
the opportunity for exceptions in a clear fashion in SQL.

Tom Liotta