[Excel] Excel rundet ungefragt

[Zvoni]

Hi Leute,

seltsames Phänomen:
Excel2019-64Bit - Win10Pro 64Bit

Per Makro ziehe ich Daten aus einer Datenbank, und spüle dann alles rüber in ein Arbeitsblatt.
Dieses Makro habe ich seit Jahren erfolgreich im Echt-Betrieb.

Seit "neustem" rundet Excel auf einmal Spalten, welche Zahlen mit Nachkommestellen enthalten (Preise).
Ich natürlich sofort in den Quellcode und per Einzelschritt die Werte geprüft.
Das Recordset selbst hat die korrekten Werte (Bsp. "157,82").
Die Zuweisung ist ein simples
MySheet.Cells(x,y) = RS("DB-SPALTE")
Format der Ziel-Zelle ist Numerisch mit 2 Nachkommastellen

Angezeigt (und als Wert selbst) ist jetzt aber auf einmal "158,00" (bzw. 158) in der Zelle selbst.

Huh?
Hat von euch jemand dieses Phänomen erlebt?

 

[Yaslaw]

So ähnlich. Ich fülle zwar die Felder nicht einzal ab sondern dumpe gleich den ganzen Recordset in eine Tabelle

MySheet.Range("A1").CopyFromRecordset rs

Ok, zu deinem Problem. Versuch es mal mit CDbl() zu erzwingen.
Anonsten setze mal ein Breakpoint auf die Zeile und schau genau, was RS("DB-SPALTE") enthält

MySheet.Cells(x,y) = CDBL(RS("DB-SPALTE"))

 

[Zvoni]

Hi Yaslaw,
CopyFromRecordset kann ich nicht benutzen, da Spalten im Zielblatt übersprungen werden.
Wie schon geschrieben: Hab per Debug/Einzelschritt im Watch/Immediate-Window die Werte des RS("SPALTE") gecheckt: Korrekt als Zahl mit Komma (Bsp 157,82)

An das CDbl hab ich auch schon gedacht.
Muss ich mal probieren.

 

[Zvoni]

OK. Rückmeldung:
Sehr seltsame Sache.
Ich hatte mich im Ursprungspost geirrt: Das ADO-Recordset selbst bekommt schon truncated Doubles
(268,85 wird im Recordset schon zu 268).
Die DB ist eine DB2 auf einer iSeries per ODBC-Zugriff.
Also erst mal DataTypeEnum des Feldes gecheckt: adNumeric, Precision und Scale mit korrekten Werten (11 und 2 wie in der DB2 selbst schon definiert).
Als nächstes die ODBC-Eigenschaften in meiner DSN geprüft: Auch alles OK.

Benutze ich jedoch das IBM-eigene Tool um auf die DB2 zuzugreifen, erhalte ich korrekte Decimals zurück (268,85).
Also liegt das Problem in den ODBC-Treiber-Eigenschaften, und dort konnte ich es nicht finden (Dezimaldarstellung steht dort auf korrektem Wert).
Ich hab es jetzt mit einem richtig bösem Hack gelöst: Ich hab in den SELECT-Befehl einen harten CAST zu CHAR gemacht, welchen ich per CDbl (bzw. impliziter Typ-Umwandlung) wieder in einen Double umwandle.
Die Performance ist dadurch natürlich mal gewaltig in den Keller, aber das ist zumindest jetzt mal die kurzfristige Lösung.

EDIT: Ich hab es auch ohne DSN (sondern mit Connection-String) getestet. Gleiches Ergebnis

 

[Zvoni]

OK, hab die "Lösung" gefunden.

Anscheinend gibt es beim ADO-Zugriff aus Office64-Bit-VBA per ODBC-DB2-Treiber einen undokumentierten Unterschied zwischen dem 32-bit und dem 64-bit-Treiber (ich habe zumindest nichts gefunden).

Die Lösung: Alle DECIMALS im SELECT-Befehl per FLOAT casten
Beispiel: "SELECT FLOAT(PREIS) AS Preis FROM SomeTable"

Kommt dann korrekt im Excel an ohne dass ich Typumwandlung machen muss bei der Zellen-Zuweisung.