Anyone know why the following is happening? ]]

This code works without the NLM:

---

DECLARE SUBROUTINE FSMSG,BTREE.EXTRACT

OPEN 'DICT.CLAIMS' TO VF.CLAIMS.DICT ELSE

FSMSG()

STOP

END

VC.SRCH.LASTNAME=EARSON"

VC.INDEX.DATA=LASTNAME.XREF" : @VM : VC.SRCH.LASTNAME : @FM

BTREE.EXTRACT(VC.INDEX.DATA, "CLAIMS", VF.CLAIMS.DICT, VC.HITS)

STOP

---

Yet with the NLM installed, the same code produces the following message (but the index is fine):

---

W602

The index record "LASTNAME.XREF**+++++++++++++++++++++++++++++++++

The indexed field "LASTNAME.XREF"

in the file "CLAIMS"

should be rebuilt.

..Press any key to continue..

---

The following code works with or without the NLM installed (only difference from previous code is EARSON instead of EARSON):

---

DECLARE SUBROUTINE FSMSG,BTREE.EXTRACT

OPEN 'DICT.CLAIMS' TO VF.CLAIMS.DICT ELSE

FSMSG()

STOP

END

VC.SRCH.LASTNAME=EARSON"

VC.INDEX.DATA=LASTNAME.XREF" : @VM : VC.SRCH.LASTNAME : @FM

BTREE.EXTRACT(VC.INDEX.DATA, "CLAIMS", VF.CLAIMS.DICT, VC.HITS)

STOP

---

Any help appreciated…

Adrian..

There have been a few recent postings here on this same topic. Try searching for BTREE.EXTRACT. Methinks the NLM has a problem with Starting and Ending operators. Have you tried an exact match to see if it also bombs? Frankly, I have not had a lot of luck with BTREE.EXTRACT and partial searches with the NLM. The same search criteria seem to work OK in R/BASIC selects or TCL selects but not always in BTREE.EXTRACT.

Don Miller

C3 Inc.

Don,

I don't understand this at all! I can't think why whether or not the NLM is active would affect the way BTREE.EXTRACT works. Would it have something to do with the intensity of I/O that a partial search (esp. an 'ending with') may result in?

Matt.

Matt..

I'm going to hypothesize a little, since I'm also puzzled by this situation (although I've seen it before). The NLM essentially breaks RTP57 into two pieces (one part on the Client and the other on the Server). Since all I/O processing is handled, in the final analysis, by RTP57, my suspicion is that there must be places where the two parts don't communicate effectively. I've seen identical pieces of code function differently using the Netware driver and the NLM. BTree Extract seems to be the one that I've seen most recently, although Index Flush also caused me some headaches in a table that contained a large number of indexes (principally, XREF's). I had a situation where users were frustrated at not being able to use XREF searches on new records until the indexes were flushed so I added an F6 key to force an Index.Flush on the table. It turned out that MOST of the values were written but not all of them. It turned out that the unflushed transactions were still in the link-list chain and a subsequent

flush would do them. Verrrrrrrrry strange.

Don Miller

C3 Inc.

Did a search regarding btree and the nlm (in general) and the only thing which really struck me as odd (or maybe not) was the absence of any input from Revelation Technologies. Known bug? If it's not, my apologies to Rev. If it is, though, how about a suggested workaround or at least a "We are aware this is a problem and are working on a solution".

In the meantime, will let our users know they cannot do prefixed wildcard searches until I have a chance to rewrite some of the routines.

Anyway, thanks to those who replied.. 'tis appreciated.

Don,

Hmmm - so my worry is that this problem isn't localized to indexing, but any form of intense I/O processing.

Matt.

View this thread on the forum...