Either I am going mad… OR

There is something about the LOCATE statement that I am not aware of… OR

There is a VERY big bug.

Trying to sort data based on a sequence number, generated by codes the user allocates to items.

Reproducable problem pasted below.

The POS generated from the LOCATE returns a value of 2, causing the inserted code to be added into the wrong location.

If I remove the first six characters (of all numbers) it works fine.

Just because it is numeric does not mean that it is not string data that should be sorted properly.

I could use AL sortation, to resolve, seeing as the sequences are the same length, but this is not the point… and in fact cannot be guaranteed anyway.

I am using OI4.0.3 on Win XP, same on Win98

Please advise, help, moan with me….

ELEM_SEQ=2829020101000107"

ITEM="

ITEM=2829020101000000"

ITEM=2829020101000106"

ITEM=2829020101000108"

LOCATE ELEM_SEQ IN ITEM BY "AR" USING @FM SETTING POS ELSE NULL

ITEM=INSERT(ITEM,POS,0,0,ELEM_SEQ)

Colin,

I'm sorry but I do not have time to test this myself right now. However, my guess is that OI is converting these to scientific notation and this is why you don't get the problem when you take out the first six numbers. There have been many threads discussing the potential pitfalls of working with a string-based language, this is one of them. A typical fix for this would be to prepend the same character before each value before you do your locate, e.g.:

ELEM_SEQ=a2829020101000107"

ITEM="

ITEM=a2829020101000000"

ITEM=a2829020101000106"

ITEM=a2829020101000108"

LOCATE ELEM_SEQ IN ITEM BY "AR" USING @FM SETTING POS ELSE NULL

ITEM=INSERT(ITEM,POS,0,0,ELEM_SEQ)

[email protected]

SRP Computer Solutions, Inc.

I agree that your guess re the scientific notation is probably what it is doing… but if so not good enough Revelation.. 1 out of 10.

I can prepend an alpha to each, but a real hassle.

I suppose I can convert @FM (or @VM) to @VM:"a", then locate/update, then convert "a" to null.

Even though, sorting three numbers 6, 8 and 7, should be something even the most basic system should be able to handle with ease, regardless of the scale.

How many programs and areas where this may occur are there around the world?

It seems to be INTEGER related and all systems have integer limits. The following snippet works though

ELEM_SEQ=2829020101000107"

ITEM="

ITEM=2829020101000000"

ITEM=2829020101000106"

ITEM=2829020101000108"

SaveITem=Fmt(Item, "R(0)#20")

ElemSave=Fmt(Elem_Seq, "R(0)#20")

LOCATE ELEMSave IN SaveItem BY "AR" USING @FM SETTING POS ELSE NULL

ITEM=INSERT(ITEM,POS,0,0,ELEM_SEQ)

return

The Sprezzatura Group

World Leaders in all things RevSoft

Colin,

Very good that you caught this!!! Interesting thing…

In OI32, it fails!

In Advanced Revelation, it works!

In another data base product (pick kinda), it works!

So, I wonder if it works in OI16???

I would expect OI to work like Advanced Revelation. So I am believing that it is a "bug". And I wonder if the conversion from 16 to 32 caused it?

I found a backup of my OI16 3.7

It fails there too. So OI fails, and Advanced Revelation works! Ouch, bacause I guess that means that all the LOCATE BY statements must be found and fixed.

Normally in database products, a string variable is a string variable. And it is left as a string variable and not converted to a numeric variable.

When converting from Advanced Revelation to OI, I guess this should be remembered.

Agreed, that both prefix and FMT will work OK as a workaround.

I will change my program accordingly, but I am still annoyed that it fails, regardless of whether it is an integer problem, whether other systems have similar problems or any other reason.

It still DOES NOT WORK.

Hey, we are nearly in 2003, and no excuses now.

Back in the 70's (yes I am that old and remember coding back then) we could have accepted the excuses. Our users dont though…..

I could even have accepted that OI16 as this problem, but we are talking OI32.

Colin

We'll look at it. Figure 4.1.3.

Mike

Brilliant Mike

thanks

But remember, this is an INTEGER issue. Even after we look at it we may not have a completely satisfactory answer- but we'll try.

View this thread on the forum...