We have a client who is getting different results on a Btree.extract

for a particular vs a Select statement for the same value.

I found a previous thread from Nov 98 which suggested the problem was either a delimeter or space messing up the index or a bug in Btree.extract where the results flag is not being set correctly.

In our case btree.extract 65526 bytes of results (10,921). The correct number of results is slightly larger than this. It seems like more than a coincidence that the 64k block size in btree.extract is equated to 65530 bytes.

Any suggestions? It's a pretty simple search just looking for the code P in a btree index. On the same index a search on another value returns 50,000 results. It seems that btree.extract is failing when the results are between 64 and 128K.

Thanks,

Matt

Vernon Systems

Matt,

Btree.Extract can't do more than 64K unless you tell it to do so. You can get it to return 64K at a time in a loop.

See .

Another feature not docced.

- Oystein -

Sorry - I didn't describe the problem enough.

I am calling Btree.extract in a loop to get more than 64k of results. In almost all cases it works fine, and I have retrieved about 60,000 record keys in some cases. In this case btree.extract is

returning 10,921 keys - 65526 bytes of data. When the client does a Select statement on the same index and value they retrieve about 12,000 results, which is the correct amount. It seems very probably that btree.extract is just passing back the first 64k of data in this case, even though there are more keys to return. In Nov 1998 Aaron Kaplan wrote that btree.extract may not be setting the return flag correctly, but there is no further discussion on this.

The same program, searching the same index, also searching on just a single value, does return more than 64k of data in other cases. It seems unlikely that it is a delimiter problem given that that data is truncated at exactly 64k.

Thanks for the replies so far.

Cheers,

Matt

Matt,

Your hypothesis is that Btree.Extract gets the first 64K of keys and then acts as if that's all there is. If I were you at least I'd be curious enough to check if it's really the last keys of the index that are missing from the returned result.

(Perhaps I'd also try to tweak the srch_strng parameter a tiny bit to see if it makes any difference.)

Btw - are you sure your index is updated? Btree.extract won't find more than what's indexed. Perhaps Select might??? (Aaaargh! That's the kind of thing one ought to know for certain, but I don't. But at least I know Rlist LIST will find unindexed stuff as well as indexed, and therefore might return more than Btree.Extract.) - Oystein - </QUOTE> —- === At 20 JUN 2001 06:50PM Matt Crozier wrote: === <QUOTE>Thanks, We have checked in the index record and the keys that are not returned by Btree.extract are definitely in there. A Select on a non-indexed field takes about 15 minutes on this file, whereas a Select on this index field takes about 10 seconds. I'm fairly convinced that the Select is just using the index, as I'd expect it to take a lot longer otherwise. We're in New Zealand and the client is in London, so it's not easy to get down to this detail. We have been doing some work through PC Anywhere to resolve this problem, but we need to get them to set it on the day. Thanks for the help so far, Matt </QUOTE> —- === At 21 JUN 2001 08:11PM Matt Crozier wrote: === <QUOTE>Would it be possible for someone from RTI to look into Btree.extract and see if there are any possible cases where the first 64k is returned, but btree.extract does not correctly set the flag to indicate there are more results to come? Is the source of OI btree.extract available (I seem to recall that it was possible to debug the ARev version)? Thanks, Matt. </QUOTE> —- === At 02 JUL 2001 06:37AM Kyle Amadio wrote: === <QUOTE>Matt email us the basic code and the dict details are we will try and replicate the details. kylea@oryx.com.au </QUOTE> View this thread on the forum...