Btree.Extract and the NLM (AREV Specific) [Revelation On-Line Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
[[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]]


==== Btree.Extract and the NLM (AREV Specific) ====
=== At 09 MAY 2000 08:16:22PM Adrian Newman wrote: ===
 
{{tag>"AREV Specific"}}
 
<QUOTE>
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...


</QUOTE>
----

=== At 11 MAY 2000 02:19PM Don Miller - C3 Inc. wrote:  ===

<QUOTE>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.

</QUOTE>

----

=== At 11 MAY 2000 05:55PM Matt Crozier wrote:  ===

<QUOTE>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.

</QUOTE>

----

=== At 12 MAY 2000 10:29AM Don Miller - C3 Inc. wrote:  ===

<QUOTE>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.

</QUOTE>

----

=== At 12 MAY 2000 08:00PM Adrian Newman wrote:  ===

<QUOTE>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.

</QUOTE>

----

=== At 14 MAY 2000 05:38PM Matt Crozier wrote:  ===

<QUOTE>Don,



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



Matt.

</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=2448266B9D257D19852568DB00017F9C|View this thread on the  forum...]]