LOCATE BY (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]]


==== LOCATE BY (AREV Specific) ====
=== At 22 APR 1999 01:34:35AM Tony Lillyman wrote: ===
 
{{tag>"AREV Specific"}}
 
<QUOTE>
I have a weird situation regarding LOCATE BY RBASIC command

I have a BTREE EXTRACT (type of) program which searches indexes to 

locate keys etc.



It uses LOCATE BY to find the Search Value in a string of values delimited by @VM.

In there simplest form, these values are ordered by Ascending-Left

ie   12345:@vm:23455:@vm:45666



If I try to 

  LOCATE 22222 in this string by "AR" using @vm setting pos else null

I get a pos value of 4 when I expect a pos value of 2 -

any thoughts ??



It has only just started to happen on a client running arev212 on Novell 312, NLM and Win95/98.



Any assistance appreciated 



Tony
</QUOTE>
----

=== At 22 APR 1999 04:25AM Oystein Reigem wrote:  ===

<QUOTE>Tony,



You say your array is ordered [i]AL[/i] but you LOCATE BY "[i]AR[/i]". Why?



But of course if all your numbers have the same length AL and AR are equal. So that cannot explain your problem.



(I see in my notes I had a similar problem once, with pos skipping to the end of the array. But I don't think I found the reason. It was in the middle of work with collation sequences in OI, with international characters, and I'd got some new code from Gene Gleyzer, to fix some bug. [i]I[/i] think of course LOCATE BY failed because a fault of Gene's code, but it [i]might[/i] have been my collation sequence. LOCATE BY does comparisons with the "" operators, and those comparison operators use the collation sequence specified in field 10 of the SYSENV*LND_... rows. If you've somehow got yourself a collation sequence where the digits have a different order than 0123456789 you might get what you get, but I really doubt that! I just mention this in case the example in your posting - with neat 5-digit numbers - is different from what you really have.)



(Btw - are you sure of the contents of your array? Do you sort it programmatically before the LOCATE BY? In case - perhaps that sort went wrong, for some yet obscure reason... ...erm... No! Certainly I must be on the wrong track here. Even if your array were incorrectly sorted, your LOCATE 22222 BY will never skip to the end. At least I think so. I think LOCATE BY starts from the beginning and plods along and compares each element. With you it will stop as soon as it encounters 23455 or 45666, whichever comes first.)



(But I might be wrong again. Perhaps LOCATE BY does a binary search instead of a sequential walk. In that case you can get unexpected results on an unsorted array.)



(Sorry for all this rambling.)



- Oystein -

</QUOTE>

----

=== At 23 APR 1999 04:04PM K Gilfilen wrote:  ===

<QUOTE>As I recall, LOCATE BY goes to where the data you give it should go in the input string, based on your sort parms. It then returns the value number in your variable, in this case, pos. 



Suppose you have the following string, which (if I'm thinking right-oops, there's a pun) is justified AL:



11111@vm2222@vm3333@vm4444444@vm5



Given this array, and an AR search using @VM, LOCATE BY will try to put 22222 in position four. 



BTW, if you sorted it AR, it would look like this:



5@vm2222@vm3333@vm11111@vm444444



And LOCATE BY (sort=AR) would, apparently by coincidence, still try to put it in position 4, though you'd end up with a different string. Here's a few questions: Are the keys strictly numeric? If so, you may want to change the dictionary to right-justify them. You'll probably get unexpected results if you don't. Like 22222 being in the fourth position, not where you expect. As the other post mentioned, you have an "AL" array, but you are searching it "AR", which implies that you think the index is sorted correctly for numbers when it isn't. 



Are you sure you are looking at the code that extracts keys, and not the code that stores them?



Well that's about as much hard thinking as I can do at one time.



Kenny

</QUOTE>

----

=== At 27 APR 1999 06:00PM Warren wrote:  ===

<QUOTE>It could be caused by an implied numeric to string conversion. What happens if you do a LOCATE "222222" in xxxx by @VM setting posn else null ?

</QUOTE>


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