Re: Missing numbers ( was Re: )

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