|
[Yoda] Deja vu strong with this one it is. [/Yoda] In 11.0.1.2276 a DECIMAL ( 30, 6 ) COMPUTE column value displays correctly as 0.000000 in dbisql but magically becomes super-duper-precise when put through UNLOAD: 000000000022222222222204938271604951714677 Is the extra BEGIN DECLARE LOCAL TEMPORARY TABLE x ( a DECIMAL ( 30, 6 ), b DECIMAL ( 30, 6 ), x DECIMAL ( 30, 6 ) COMPUTE ( ( ( a - b ) / b ) * 100.0 ) ); INSERT x ( a, b ) VALUES ( 999999999999999999999999, 999999999999777777777777 ); SELECT @@VERSION, * FROM x; UNLOAD SELECT @@VERSION, * FROM x TO 'C:\temp\x_table.txt'; END; /* -- The first SELECT in dbisql... @@VERSION,a,b,x '11.0.1.2276',999999999999999999999999.000000,999999999999777777777777.000000,0.000000 -- The file produced by the UNLOAD... '11.0.1.2276',999999999999999999999999,999999999999777777777777,.000000000022222222222204938271604951714677 */ |
Follow this question
By Email:Once you sign in you will be able to subscribe for any updates here
By RSS:Markdown Basics
- *italic* or _italic_
- **bold** or __bold__
- link:[text](http://url.com/ "title")
- image?
- numbered list: 1. Foo 2. Bar
- to add a line break simply add two spaces to where you would like the new line to be.
- basic HTML tags are also supported
Question tags:
question asked: 20 Nov '10, 15:07
question was seen: 1,977 times
last updated: 29 Nov '10, 21:35
Just a similar effect with DOUBLE: When comparing the UNLOAD result for a migrated database with different SA versions, I remember to have had situations where the same double value was unloaded to different numbers. The differences were apparently in the range beyond the significant 15 digits, but I still was stumbled that a value could produce different results before and after a migration. I asked in the newsgroups but didn't get a real explanation... For DECIMAL, it's even more of a surprise:)
[Volker said: For DECIMAL, it's even more of a surprise:)] ...yeah, it was a complete Deer In The Headlights moment, woulda gone viral on Youtube if a camera had been pointed at me :)
The extra precision does appear to be getting stored. As far as I can tell, UNLOAD is just printing the value that it found in the column so the problem would appear to be a lack of an appropriate cast/rounding during the insert. I'll let someone from query processing comment / look into it.