Fehlermeldung: 0,0135 ist kein gültiger BCD-Wert

[Bbommel]

Hallo zusammen,

bei einem Kunden bekomme ich beim Zugriff auf eine MSSQL-Datenbank via ADO immer wieder Fehlermeldungen, die so oder so ähnlich aussehen, wie die oben im Betreff angegebene.

Die Spalte ist auf dem SQL-Server definiert als "decimal(38,20)". Bei mir im Code steht an der Stelle einfach nur

Delphi-Quellcode:

Menge:=currQuery.Fields[10].AsFloat;

Wenn ich mir die ganze Tabelle in ein TDBGrid ausgeben lasse, steht an der entsprechenden Stelle dann "BCD-Überlauf".

Der Spaß ist: Wenn ich das Problem des Kunden auf meiner Entwicklungsumgebung nachstelle, funktioniert alles. Schreibe ich also bspw. den Wert 0,0135 als Menge in die Datenbank, so wird dieser tadellos gelesen oder im TDBGrid angezeigt.

Hat irgendwer eine Ahnung, woran das liegen könnte? Google hat mir etwas von einem Bug ausgeworfen - ist das etwa die Ursache? Aber warum funktioniert das gleiche dann bei mir?

Ratlose Grüße
Bommel

[Luckie]

Wie sind den die Einstellungen des Dezimaltrennzeichens bei dir und dem Kunden? Und wie ist es in der Datenbank definiert, wenn man es denn da einstellen kann.

[shmia]

Delphi hat bei BCD-Feldern nur eine interne Genauigkeit von 4 Nachkommastellen weil der Wert in einem Currency-Datentyp aufbewahrt wird.
Das bedeutet, dass die Datenbank eine höhere Genauigkeit hat, als Delphi darstellen kann.
Die einfachste Lösung des Problems wäre die Numerischen Felder auf DEC(16,4) zu reduzieren.
Die übertrieben hohe Genauigkeit der Felder wurde sicher nur aus Faulheit und/oder Unwissenheit gewählt.

Ansonsten gibt es auch noch die Möglichkeit, bei der ADO-Query das Property EnableBCD auf False zu setzen. (Nachteil: Rundungsfehler sind möglich/wahrscheinlich)

[Bbommel]

Hallo,

@shmia: vielen Dank für den Hinweis auf EnableBCD - das klingt doch vielversprechend und ich lasse das den Kunden gerade mal testen. Mich wundert zwar, dass es bei mir funktioniert hat und bei ihm nicht, aber wer weiß, woran sowas wieder liegt. Die Felddefinition zu ändern, ist leider keine Option, da das eine Dynamics NAV-Datenbank ist, da kann/will ich nicht mal eben so die Felder zerschießen. ;)

@Luckie: Danke auch für deinen Tipp. In die Richtung hatte ich zuerst auch geforscht, aber bei MSSQL konnte man in die Richtung nichts einstellen (habe zumindest nichts gefunden) und letztlich geht es ja auch nicht um eine Umwandlung von Strings.

Bis denn
Bommel

[Luckie]

Ok, dann habe ich daneben gelegen. Aber ich kenne mich mit Datenbanken nicht so aus.

[shmia]

Zitat:

Zitat von Bbommel (Beitrag 1094355)

Mich wundert zwar, dass es bei mir funktioniert hat und bei ihm nicht, aber wer weiß, woran sowas wieder liegt

Wenn z.B. das Feld in der Tabelle den Wert 0.013500000000001 hat, dann wird wahrscheinlich (bin mir nicht sicher, weil ich diese Delphi-Version nicht habe) die besagte Exception ausgelöst, weil der Wert nicht exakt im Datentyp Currency gespeichert werden kann.
Das ist im Prinzip richtig, weil bei einem BCD-Feld der Anspruch besteht, dass keine Genauigkeit verloren gehen soll.
Ältere Delphiversionen haben wahrscheinlich stillschweigend die Nachkommastellen abgeschnitten.

Wenn man die Tabelle mit dem SQL Management Studio öffnet, müssten eigentlich alle Nachkommastellen zu sehen sein...

[Bbommel]

Hallo noch mal,

zunächst die gute Nachricht: Mittlerweile habe ich auch vom Kunden die Rückmeldung, dass jetzt alles funktioniert. Vielen Dank also noch mal für die Hilfe.

Was das (Nicht-)Auslösen der Exception angeht: Beim Kunden und bei mir ist es ja die selbe .exe aus meinem Delphi, also in beiden Fällen D2009. Der Unterschied ist natürlich, dass bei mir Delphi installiert ist und bei ihm nicht. Aber ob das der Grund ist, dass der Fehler mal auftaucht und mal nicht, glaube ich nicht.

Ich vermute eher etwas in die Richtung: Beim Kunden wurde der krumme Wert durch Dynamics NAV in die DB geschrieben, ich habe das bei mir (im Management Studio) manuell selbst gemacht. Vielleicht müsste ich in die Richtung noch mal testen, aber eigentlich ist das Problem ja gelöst, wäre also eher "akademisches" Interesse. :)

Bis denn
Bommel

[Jumpy]

Nur mal so gefragt, weil ich mich darüber schonmal gewundert habe. Kann das auch an ADO liegen?
Sprich die ADO-Komponente liefert ja mMn nicht immer die genaue Typdefinition der Datenbanktabelle, sondern den ADO-Typen, von dem ADO denkt, dass er dazu passt.

[shmia]

@Jumpy: ja, ich denke damit liegst du ganz richtig.
Es gibt es ein doppeltes Mapping der Datentypen der Felder:

Code:

native Type (DB) <-> ADO Type <-> VCL TField - Klassen

Dabei hängt es vom OLE-DB Provider (oder auch vom ODBC-Treiber) ab, wie zugeordnet wird.