Debugger and Quantities

klavin

Anyone ever see this? Was frustrating today. We have an order screen for some EDI Orders to easily see quantity vs. qty on pick's in WMS Environment. We highlight the suspect lines blue for a visual aid...

Debugger shows both quantities are 51, but is hitting the BlueHighlight... I ended up popping messages FORMAT("Qty. On Pick") and found: "Qty. On Pick" (a flowfield) was:
51.0000000000000001.

Though oddly enough, the quantity on pick truly is 51. Both Quantities FORMAT to 51... Very odd.

I was just curious if anyone saw something that weird...

Belias

51.000000001 is the sql value (approx to 15th decimal)
i remember that one time i had an instruction like:

if myvalue1 = myvalue2 then begin
...
end;

which failed for this reason (i've not to tell you how frustrating was to debug it)
even thought i don't know why does it happen, i corrected the sql value, directly in SQL; your field is a flowfield (sum flowfield, i think) so you'll probably have to recreate the SIFT/VSIFT. If the problem is not solved yet, check the table from where the SIFT is calculated, and correct the value(s).
Be careful in modifying data directly in sql, because the business logic is not executed!
I hope I explained well, and i hope someone tell us why does this happen

klavin

Yeah Belias I agree. I did rebuild the indexes yesterday with the Optimize from Table Information as well hoping that would resolve the issue quickly, but it didn't. This is an isolated incident, but I'm going to try completely rebuilding the key and see if that changes anything.

I just thought it was very weird...

Belias

be sure to check the table from where the SIFT is calculated, too...because if the data in the original table is the cause of the wrong flowfield, it doesn't matter how many times you rebuild the sift/VSIFT, because sql will see that 0,0000000001 in the original values, and it'll use it for his sum, thus polluting the aggregated value.

klavin

Yeup, I did the Sales Line (where flowfield is), and Warehouse Activity Line (where it flows from). I thought rebuilding Warehouse Activity Line was going to do it, but... nope I'll try rebuilding the key ground up, see if the rounding fixes, just need to wait for SQL Backup to restore.

I did check the SQL Values on Warehouse Activity Line for those, and they both were 51 as well.
Thanks Belias... Should have seen me yesterday staring at the debugger and the values of everything going... "What the heck is going on"

Belias

klavin wrote:

Yeup, I did the Sales Line (where flowfield is), and Warehouse Activity Line (where it flows from). I thought rebuilding Warehouse Activity Line was going to do it, but... nope I'll try rebuilding the key ground up, see if the rounding fixes, just need to wait for SQL Backup to restore.

I did check the SQL Values on Warehouse Activity Line for those, and they both were 51 as well.
Thanks Belias... Should have seen me yesterday staring at the debugger and the values of everything going... "What the heck is going on"

i probably missed something in your post because of your english is too......english
where were the problem then? was there a value in the "warehouse activity line"."quantity" with 0,0000001 decimal or not?
what i understood from your post is that you restored a backup and all got back to normal --> this PROBABLY means that the wrong value was actually a quantity with 0,0000001 in warehouse activity line...
If i've been helpful, you're welcome!

klavin

Sorry Belias,

No, let me describe it better, I've jumped around too much I think

Sales Line - Quantity: 51 (In running table and looking at SQL table and Debugger, when FORMATed)
Sales Line - "Qty. On Pick": 51 (According to Debugger). If I do MESSAGE(FORMAT("Qty. On Pick")); it is 51.0000000000000001.

Flowfield is summing from Warehouse Activity Line...

Warehouse Activity Line - Quantity: 51 (In Table, when FORMATed, in SQL)

I just deleted the key in Warehouse Activity Line, compiled, readded... still wrong.
I was taking the backup just to restore the same "live" SQL on my development environment to delete the key. It still is wrong; doesn't make sense. Out of all the orders we've had and all of the orders still in the system, this is the only one acting this way. There is no unit of measure conversion in question, quantities in Warehouse Entry are all correct.

Belias

:-k
so, the problem does not exist?did you try to query your sql database (from sql server management studio)?

select * warehouse activity line where Quantity > 51 AND quantity < 51,1

?

klavin

Exactly. It doesn't exist, but it does in the flowfield?

SELECT * FROM [Company$Warehouse Activity Line] WHERE [Quantity] > 51 AND [Quantity] < 51.1
(0 row(s) affected)

Belias

sorry, wrong query: is it possible that the 51.000000001 value is generated from a quantity of 30 and one quantity of 21.00000001?in that case the query i posted is useless :oops:
i don't know what query you can use to see if there's a value containing a little decimal...probably something like quantity MOD 0,0000001 = 0
(use 6 zeroes: in this way every quantity will return 0 except the one with 15-16 zeroes and a trailing 1)
btw, what is your NAV version? i mean, is nav using SIFTs or VSIFTs?

klavin

Yeah, for your example it was correct. The Pick line is only 1 line of 51 quantity.
We are using NAV 5.0 SP1 so VSIFT.

If I execute a query against the table (I know its not the vsift) with the exact parameters of the FlowField the result is 51 as well.

SELECT [Quantity] FROM [Company$Warehouse Activity Line] WHERE [Source No_] = 'SO-0283930' AND [Action Type] = 1 AND [Source Line No_] = 40000

Action Type::Take

51.00000000000000000000

EDIT: Also doing:
SELECT * FROM [Company$Warehouse Activity Line$VSIFT$22] WHERE [Source No_] = 'SO-0283930' AND [Action Type] = 1 AND [Source Line No_] = 40000

Results: