Dunno if this has been posted here before,
but I ran across a strange bug with the
'AL' variant of LOCATE() on uniData 7.2
which is illustrated in this uniBASIC
program:

CODES = CHANGE('A,7,7B,7',',',@AM)
LIST = ''
FOR I = 1 TO DCOUNT(CODES,@AM)
CODE = CODES<I>
LOCATE(CODE,LIST,1;POS;'AL') ELSE LIST = INSERT(LIST,1,POS;CODE)
LOCATE(CODE,LIST,2;POS) ELSE
FOR POS = 1 TO DCOUNT(LIST<2>,@VM)
IF CODE < LIST<2,POS> THEN EXIT
NEXT POS
LIST = INSERT(LIST,2,POS;CODE)
END
NEXT I
CRT CHANGE(CHANGE(LIST,@VM,';'),@AM,CHAR(10):CHAR(13))


The output of the program is this:

7;7B;A;7 <-- note the ending "7" !
7;7B;A


The first locate, with the 'AL' variant,
produces the first list, with the '7'
value repeated (in error) at the end.

The second locate, with the subsequent
FOR/NEXT loop, does the right thing.

Anybody seen this before?

Is there a tweak to uniBASIC that will
fix the LOCATE() with the 'AL' variant,
in the case that some of the values
are numeric, some are alpha, and some
are mixed?

--
frosty

On Sep 21, 12:22*am, "frosty" <fros... (AT) bogus (DOT) invalid> wrote:
Frosty,

Output in Unidata 7.1.8:
7;7B;A
7;7B;A
For both 'U' and "P' types. Version 7.2 bug?

Tom

I can replicate this on UD 7.1.6 on Windows if I turn UDT.OPTIONS 85
ON. The default is OFF.

hth
Colin Alfke
Calgary Canada

On Sep 20, 10:22*pm, "frosty" wrote:

"Colin" <ud.u2.man (AT) gmail (DOT) com> wrote

Thanks, Colin, that's exactly my problem.
Turns out we turn option 85 ON at LOGIN,
to fix some _other_ problem with LOCATE().

--
frosty

"tpc" <gfmrider (AT) gmail (DOT) com> wrote


I think it will fail on 7.1.8 with
UDT.OPTIONS 85 ON (see another reply
to this thread.)

Thanks for testing it for me.

--
frosty

You'll probably fix this with a UDT.Option, but let's assume for now,
in case someone else has a similar issue, that it's a bug that won't
be curable until you get a DBMS patch/upgrade.

Given that CODE can be alpha or numeric and you want everything
processed as alpha, I'd say force it to alpha and then back with the
following:
FOR I=1 TO CT
LOCATE("X":CODE,LIST,1;POS;'AL') ELSE
LIST = INSERT(LIST,1,POS;"X":CODE)
LIST<1,POS> = LIST<1,POS>[2,999]
END
NEXT I


That extra line could be:
LIST<1,POS>[1,1]=""
or
LIST<1,POS> = LIST<1,POS>[2]
depending on the platform ... I don't recall what syntax UD supports
atm.

HTH
T

On Sep 21, 9:30*am, "frosty" wrote:
Yes, it allows negative numeric values to sort numerically. The good
thing is that you can change UDT.OPTIONS to do what you want - the bad
thing is that sometimes you have to be really careful about what you
want...

No idea why it sorts the 7 after the 'A' and then the '7B' before the
'A'. That doesn't seem right in any case - especially if it's thinking
they're HEX values.

You could do a "full" locate first and then the insert - but it still
may not be sorted as expected. Otherwise you can use Tony's suggestion
to force it to a string by pre-pending it with an 'X'.

Note:
LIST<1,POS>[1,1] = "" syntax nulls the first character in the string
for UniData BASICTYPE "P" but in BASICTYPE "U" it's changed to a
space.
The var = LIST<1,POS>[2] results in the last two characters being
assigned to var (in both BASICTYPES).

I wonder how many other platforms support UniData's little known
(undocumented?) feature of using the [] like the 'g' conversion code:
VAR = "9*qwer*55*456AA"
VAR['*',2,1] = "NEW"
CRT VAR
:9*NEW*55*456AA

Colin