Anmelden

View Full Version : Kommazahlen beim Export



Spoldo
14-03-05, 13:19
Hallo,

wie kann das bitte sein?
In einer db2 PF habe ich den Wert 19,2 gespeichert. Das Feld ist formatiert als 4/1 S. Auf diese PF greife ich per ODBC Verknüpfung aus Access zu. Ich übernehme die Daten mit einem 'SELECT INTO ....' in eine lokale Access-Tabelle.

Wenn ich das Feld in der Access-Tabelle als Double mit 15 Nachkommastellen formatiere, bekomme ich den Wert 19,2000007629395 angezeigt. Warum :confused:?


Bin dankbar für jeden Hinweis.

Fuerchau
14-03-05, 13:43
Double-Werte werden als 64-Bit intern zur 2er-Potenz gespeichert.
Ein Dezimalwert wird also umgerechnet !
Der Bereich ist dann eben
+/- 0 - 0,5 * 2 ^ X
Alle ganzen Zahlen lassen sich glatt in 2er-Potenz darstellen (als BIN-Wert).
Nachkommastellen sind allerdings fast immer Näherungswerte, da auch diese in 2er-Potenzen berechnet werden:
0,5 = 1/2
0,25 = 1/4
0,125 = 1/8
Nun ergibt sich also dass 0,2 dezimal nicht genau bei Double darstellbar ist !
0,2 = 1/8 + 1/16 + 1/128 + 1/256 + 1/2048 + 1/4096 + .....

Die gesamte Genauigkeit ist dann ca. 17 Stellen * 10^300

Daher gibt es den Feldtyp CURRENCY, bzw. für Access als Typ: Zahl Dezimal !
Da gibt es max. 18 Ziffern genau, und daher mit größeren AS/400-Dezimalfeldern z.B. dec(30,5) nicht verwendbar.

Spoldo
14-03-05, 14:13
Aber currency macht doch wohl nix anderes als zu runden, oder ?

Fuerchau
14-03-05, 14:22
Nein !
Currency wird IMMER als Ganzzahl in 16/32/64 Bit gespeichert (abhängig von der Genauigkeit), währen die Kommastelle nur "gedacht" ist und nicht wie beim Double tatsächlich einen Wert darstellt.
16 Bit max. 4 Stellen
32 Bit max. 9 Stellen
64 Bit max. 18 Stellen
Daher ist 0,2 dann auch tatsächlich 0,2 weil z.B. bei Currency(18,4) die interne Darstellung 2000 * 1/(10^4) ist.
Beim Rechnen kann es dann ggf. zu Überlauffehler kommen.

Spoldo
14-03-05, 14:27
Okay, klasse. Dann ist das ja genau das was ich brauche.

Danke