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

Tony,

You say your array is ordered AL but you LOCATE BY "AR". 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 think of course LOCATE BY failed because a fault of Gene's code, but it might 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 -

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

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 ?

View this thread on the forum...