Ich habe ein klitzigkleines Problem beim Auslesen von Gleitkommawerten aus der DB mit eine TSQLQuery. Konkret habe ich einen Wert 8,5 in der DB, erhalte aber 85 beim auslesen. Die Query liefert mit das Feld als TFmtBcdField http://docwiki.embarcadero.com/Libra...B.TFMTBCDField, was angeblich eine bessere Genauigkeit hat und für Währungen verwendet wird. Ich will aber lediglich eine z. B. 8,5 im Programm als 8,5, meinetwegen auch als 8.5 bekommen….und nicht als 85!!



Sherlock

Tja, Dezimalfelder sind ein echter Schwachpunkt von Delphi.
Gerade bei Oracle hatte ich damit auch schon öfters Probleme.
Delphi kennt ja den Datentyp Currency; ein Festkommaformat mit dezimalen 4 Nachkommastellen (64 Bit).
Leider gibt es in Delphi keinen Festkommadatentyp mit 128Bit wie z.B. Decimal in C#.

Wenn du auf ein BCD-Feld zugreifst dann solltest du es mit .AsCurrency und nicht als .AsFloat oder .Value auslesen.
Achte auch darauf ob in der Felddefinition in Oracle mehr als 4 Nachkommastellen hinterlegt sind; notfalls auf max 4 Stellen verringern.

1. Ich verwende eigentlich die DOA von AllroundAutomations und habe seit über 10 Jahren keine Probleme mit Oracle gehabt. Die hab ich mir halt für XE5 noch nicht gleistet, weil ich noch am evaluieren bin.
2. Diese Grundtypen korrekt auszulesen ist eine Minimalanforderung an DB-Komponenten.
3. Es klappt auch mit .asCurrency nicht...bleibt bei 85
4. Ich bin sowas von verärgert... Aber Hauptsache man kann jetzt in seinen "Business-Apps" Animationen wiedergeben

Sherlock

Die haben ein Update vom 3.10 für XE5.

Wenn deren Schnittstelle nicht geht, dann ist das doch das Problem von denen oder sehe ich das Falsch

Ist zwar schon etwas alt, aber vielleicht hilft es dir ja doch weiter. Meine Google-Suche hat folgenden Hinweis aufgetrieben:
http://de.comp.lang.delphi.datenbank...ber-bcd-felder

arnof: Ich habe mich wohl missverständlich ausgedrückt. Ich verwende derzeit für XE5 (notgedrungen) dbExpress und nicht AllroundAutomations. Mir ist klar das die eine passende Version haben, von der ich ausgehe, daß sie funktioniert.

baumina: Das hatte ich nicht gefunden, es ist genau mein Problem. Ich behelfe mich aber mittlerweile indem ich die SQL-Abfrage so formuliere, daß die Ergebnisse als wohlformatierte Strings zurückkommen. Sind ja nur drei solche Felder in meinem Demoprojekt.

Wie baumina zeigte ist dieses Problem mindestens 10 Jahre alt. Und nicht gefixt. Noch etwas für MEissing

Sherlock

Zitat von Sherlock:

Noch etwas für MEissing

QC Eintrag?

Es gibt ca. 60 QC Einträge zum Thema BCD ...

Zitat von MEissing:

Zitat von Sherlock:

Noch etwas für MEissing

QC Eintrag?

http://qc.embarcadero.com/wc/qcmain.aspx?d=2742
Jetzt sachste eventuell: "Das ist ja geschlossen" Da sag ich: "Jo, aber nicht gefixt, sondern nur geworkaroundet".
Und den Workaround muss man auch erstmal suchen. Das ist halt die Sache. Wenn man keine Zeit/Resourcen hat ein Problem zeitnah zu fixen, gibts ein Workaround, bis der Bug behoben ist. Hier hat man aber nach dem Workaround abgebrochen...und 11 Jahre sind IMHO genug Zeit um das zu fixen.

Noch ein kleines Quote aus der QC von John Herbster:

Zitat:

Here is a list of QC reports of FMTBCD problems:
1236 -- Complaint about lack of real decimal fraction numbers.
1389 -- Bug in the RoundAt function. (Closed, fixed)
2721 -- BCD fields retrieved with error (missing decimal point)
2732 -- Formatting problem
2741 -- Am guessing this is problem using TBCD with floating point DB field.
4281 -- Feature request to # fields bind to FmtBCD
6013 -- Divide error (this report)
8251 -- Fields defined like NUBERIC(15,5) are not fetched correctly
9967 -- Error when comparing an FMTBCD variant value with constant value
10275 -- FormatBCD and division operation of TBCD failed in FMTBcd unit.
10582 -- Found an uninitialized variable of method TFMTBcdData.DoDivide in unit FMTBcd.pas

Sherlock

Eine Antwort hätte sein können: "OK, schau ich mir demnächst mal an."
Ich hätte auch mit "Muss die Roadshow vorbereiten, melde mich im Dezember wieder" leben können.

Eisiges Schweigen habe ich jedoch auf keinen Fall erwartet. Ich hab ja wirklich nichts garstiges geschrieben. Da war ein Smiley drin, verdammichnocheins...

Da sag noch einer, an der schlechten Kommunikation sind allein die Käufer (bitte dieses Wort im Hinterkopf behalten) Schuld

Sherlock