Further to my earlier thread, we've come up with a little more information–but no solution:

In no particular order,

1. TCL SELECT never calls BTree.Extract – how does it do its index lookups any better?
2. The only 16,382 keys returned by BTree.Extract are identical to the first 16,382 keys returned by TCL SELECT.
3. The first key not returned by BTree.Extract does not reside at the beginning or end of a BTree leaf node.
4. Neither the last key returned nor the first key not returned contains any special characters
5. The true result of our search consists of a nearly unbroken contiguous range of keys–This is the only thing we've noticed that might be "different."
6. AREV 3's manuals have better documentation for BTree.Extract–including the multiple-call syntax–than OI's. OI's manuals, on the other hand, include documentation on the %USER.INDEX% functionality, which AREV's do not.
7. The %USER.INDEX% feature of BTree.Extract doesn't look like it would give us access to the record keys involved, so it's not likely to help.
8. The source code for BTree.Extract (and all its hapless slaves ;)would be mind-bogglingly useful to us. :)

Caveat: Our record keys are "crunched"–that is, they are base-246 packed binary integers, made up of one or more of \01\,\F7\. We suspect that this is the ultimate source of the problem, but a) We can't do anything about it due to a large installed base, and b) As long as we don't use any \00\'s or system delimiters in our keys, we should have nothing to worry about, right? …right? ;)

Thanks for your time,

acruise@istar.ca

Eloquent Systems Inc. [img]http://www.eloquent-systems.com/esyslog5.gif[/img] </QUOTE> ---- === At 01 NOV 1998 05:00PM akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura, Inc. wrote: ===

Select doesn't do loopups any better than btree.extract, it does them differently.

Btree.extract will not split up lists based on nodes, but based on length. If there is more there, then it adds it into some common var and stores it for retrieval on the next handle pass.

So, one of two things is happening. You have a key which somehow tells btree.extract or idx_sets there is nothing more processed (an errant delimiter or a few spaces or something) or somehow the return handle is not being set.

You might try calling btree_extract again, even though there is no reason to try, and see if the keys will give back more information anymore information.

akaplan@sprezzatura.com

Sprezzatura, Inc.

---

=== At 02 NOV 1998 10:33AM Oystein Reigem wrote: ===

Alex,

I've mailed you on info@eloquent-systems.com with some less likely causes…

- Oystein -

---

=== At 02 NOV 1998 03:27PM Alex Eloquent wrote: ===

Aaron,

Select doesn't do loopups any better than btree.extract, it does them differently.

Given this problem, from my admittedly subjective perspective, it is better. ;)

So, one of two things is happening. You have a key which somehow tells btree.extract or idx_sets there is nothing more processed (an errant delimiter or a few spaces or something) or somehow the return handle is not being set.

Well, the first scenario (delimiters) is unlikely, since our key conversion specifically excludes ASCII characters higher than #247. However, if spaces (\20\ specifically) in the keys cause a problem, that might be an answer–we have them in quantity.

You might try calling btree_extract again, even though there is no reason to try, and see if the keys will give back more information anymore information.

We tried this, and didn't get anything back.

Thanks for your time,

acruise@istar.ca

Eloquent Systems Inc. [img]http://www.eloquent-systems.com/esyslog5.gif[/img] </QUOTE> ---- === At 07 NOV 1998 02:40PM akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura, Inc. wrote: ===

Try passing a D in options (just add it on to the list if there are any) or set @USER0 or @USER1 to 'DEBUG' (case is important but I can't remember which @USER, so you might as well use the D option.

This will put BTREE.EXTRACT into Debug mode.

Sorry all, I don't think this is in OI, just ARev

akaplan@sprezzatura.com

Sprezzatura, Inc.

View this thread on the forum...