[Firebird]

[MyRealName]

Hallo zusammen,

haben gerade mal einen Fehler in einer Berechung von Daten in der datenbank gesucht und sind auf ein recht seltsames Verhalten gestossen :

Ich schreiben in Tabelle 1 den Wert 422,24 rein. Das Feld ist als Numeric(15,5) gekennzeichnet (brauche 5 Nachkommastellen).
Eine Stored Procedure kopiert den wert dann (über eine Variable die ebenfalls als Numeric (15,5) angelegt ist in einer 2. Tabelle, wo das Feld Feld auch als Numeric(15,5) angelegt ist. Kein Trigger verändert den Wert, aber er kommt als 422,23999 dort an und wird von dort auch mit diesem Wert weiter verarbeitet

Das verursacht Probleme in der Berechnung später, wenn ich zum Beispiel einen Durchschnittspreis berechne und ich 422,24 Einheiten wegnehme, dann habe ich Werte wie -0,0099976 und dann dann dividiert durch einen Wert ergibt ziemlich doofe Zahlen :0

Idee, woran sowas liegt ? Ist es ein generelles Firebird Problem ?

Danke schonmal,
Helge

[Sir Rufo]

Das Problem ist nicht Firebird sondern Delphi (bzw. der Datentyp den du verwendest).

Siehe hier

Ganz besonders wichtig ist dieser Artikel (englisch)

[MyRealName]

Etwas seltsames ist mir aufgefallen :

ich habe 2 Stored Procedures, die den wert kopieren, beiden arbeiten mit der gleiche Variablen-Definition, Numeric (15,5).
Die eine, wir im originalen Post schon geschrieben, wandelt mit die Daten um. Die andere nicht. Da kommt die Zahl als 422.24 an, anstatt 422,239997 etc

[MyRealName]

Zitat von Sir Rufo:

Das Problem ist nicht Firebird sondern Delphi (bzw. der Datentyp den du verwendest).

Siehe hier

Ganz besonders wichtig ist dieser Artikel (englisch)

Weiss nicht, ob Delphi das Problem sein kann, da der Fehler in der Stored Procedure passiert. In der Originaltablle, wo Delphi reinschreibt, kommt derWet ja korrekt an.

[Dejan Vu]

Wie kopierst Du denn die Werte in der Stored Procedure? Nicht, das Du da eine Variable verwendest, die irgendwie als 'Float' oder 'Double' deklariert ist.

[Lemmy]

welchen Dialekt hat die Datebank?

Den bekommst Du so raus:

Code:

isql <Datenbank> -user <> -password <>

SQL> show sql dialect;
Client SQL dialect is set to: 3 and database SQL dialect is: 3

wenn hier irgend wo was vom Dialect 1 die Rede ist, dann ist das Verhalten klar, denn unter Dialect 1 werden Numerics und co. als Doubles gespeichert

[MyRealName]

Zitat von Lemmy:

welchen Dialekt hat die Datebank?

Den bekommst Du so raus:

Code:

isql <Datenbank> -user <> -password <>

SQL> show sql dialect;
Client SQL dialect is set to: 3 and database SQL dialect is: 3

wenn hier irgend wo was vom Dialect 1 die Rede ist, dann ist das Verhalten klar, denn unter Dialect 1 werden Numerics und co. als Doubles gespeichert

also dein befehl gibt das folgende aus : http://puu.sh/8SqgB.png
scheinbar 3.

und wie gesagt, die variable beim kopieren ist als Numeric(15,5) deklariert, genauso wie das source-feld und das Zielfeld.

[Lemmy]

Zitat von MyRealName:

und wie gesagt, die variable beim kopieren ist als Numeric(15,5) deklariert, genauso wie das source-feld und das Zielfeld.

schon klar, nur im Dialect 1 werden die halt dennoch als Double gespeichert, weil es da keinen Int64 gibt.

Gibt es eine Chance die betreffenden Tabellen und StoredProcedure als Sourcen zu sehen?

[MyRealName]

Zitat von Lemmy:

Zitat von MyRealName:

und wie gesagt, die variable beim kopieren ist als Numeric(15,5) deklariert, genauso wie das source-feld und das Zielfeld.

schon klar, nur im Dialect 1 werden die halt dennoch als Double gespeichert, weil es da keinen Int64 gibt.

Gibt es eine Chance die betreffenden Tabellen und StoredProcedure als Sourcen zu sehen?

klar

aber ich habe gerade was anderes gefunden, was vielelicht Aufschluss gibt, von daher (auch weil die sourcen teilweise recht lang sind) heben wir uns das für danach auf

Also wenn ich die stored procedure vom Programm aufrufe, dann hat diese den Wert als 422.24 in der 1. Tabelle (wird durch UniDac in Delphi geschrieben) und die SP kopiert den Wert dann als 422.23999 in die Tabelle 2.

Rufe ich nach dem Speichern in der 1. Tabelle die SP direkt in SQL auf, kopiert er korrekt :O

Gerade ind en Verbindungs-Eigenschaften von TUniConnection nachgeschaut, verbindet auch mit SQL Dialekt 3

[mkinzler]

Delphi speichert den Wert als Delphityp zwischen, da es keinen nativen Fixed Point gibt nimmt er halt einen Float.