Firebird und Numeric fields

[MyRealName]

Numeric(9999,4) geht nicht, geht in firebird scheinbar "nur" bis 18.
Eigentlich wollte ich ja numeric(18.4) für alle Currency-Felder, aber jede mathematische Op in firebird erzeugt daraus ein 18,8... dann passen da nur noch 1.234.567.890,12345 rein, also man grad 310k euro in Pesos.

und das problem habe ich nicht in Delphi, osndern nur in Firebird. In Delphi kann cih mit Currency für geld arbeiten und bei Inventar-Mengen mit extended und CompareValue.

[Lemmy]

Zitat von MyRealName:

Eigentlich wollte ich ja numeric(18.4) für alle Currency-Felder, aber jede mathematische Op in firebird erzeugt daraus ein 18,8...

bei mir nicht.. welche Firebirdversion hast Du denn? Die 2.1 macht das problemlos mit:

Code:

CREATE TABLE Test (
test1 Numeric(18,4),
test2 Numeric(18,4),
test3 Numeric(18,4));


INSERT INTO test VALUES (2.5, 5, 0);

UPDATE test SET test3=Test1*test2;

Und selbst wenn das in neueren Firebird geändert wurde, was spricht denn gegen ein

Code:

Select cast(test1*test2 AS Numeric(18.4)) from test

Grüße

[MyRealName]

Zitat von Lemmy:

Zitat von MyRealName:

Eigentlich wollte ich ja numeric(18.4) für alle Currency-Felder, aber jede mathematische Op in firebird erzeugt daraus ein 18,8...

bei mir nicht.. welche Firebirdversion hast Du denn? Die 2.1 macht das problemlos mit:

Code:

CREATE TABLE Test (
test1 Numeric(18,4),
test2 Numeric(18,4),
test3 Numeric(18,4));


INSERT INTO test VALUES (2.5, 5, 0);

UPDATE test SET test3=Test1*test2;

Und selbst wenn das in neueren Firebird geändert wurde, was spricht denn gegen ein

Code:

Select cast(test1*test2 AS Numeric(18.4)) from test

Grüße

http://www.firebirdfaq.org/faq79/

Zitat:

Here's an example: if you multiply 9.12 with 8.11 (both numeric(18,2)) you would get 73.9632. If Firebird would store that into numeric(18,2) datatype, we would lose 0.0032. Doesn't look much, but when you have complex calculations, you can easily loose thousands (dollars or euros). Therefore, the result is stored in numeric(18,4).

[himitsu]

A * B * C * D * E * F * G * H -- alles numeric(18.2) ergibt dann also numeric(18.16) ?

Ich hätte eher erwartet, dass hinten das raus kommt, was als "größter" Typ rein ging.

[MyRealName]

Zitat von himitsu:

A * B * C * D * E * F * G * H -- alles numeric(18.2) ergibt dann also numeric(18.16) ?

Ich hätte eher erwartet, dass hinten das raus kommt, was als "größter" Typ rein ging.

Ich auch, aber das ist, was bei firebird auf der Seite steht...

Mein Ansatz im MOment ist es, dass ich es händisch vielleicht selbst mache... alles mit 10.000 multiplizieren und in einem Bigint speichern und damit rechnen und dann alles durch 10.000 dividieren und dann in ein Numeric(18,4)

[hstreicher]

Zitat von himitsu:

A * B * C * D * E * F * G * H -- alles numeric(18.2) ergibt dann also numeric(18.16) ?

Ich hätte eher erwartet, dass hinten das raus kommt, was als "größter" Typ rein ging.

ja, so kommt das raus , ist aber glaube ich SQL Standard
das Problem löst man mit einer Cast "Orgie" um die Overflows die sich bei längeren Berechnungen ergeben abzufangen

also

Code:

cast(cast(cast(a*b as numeric(18,4))*c as numeric(18,4))*d as numeric(18,4))

http://www.firebirdsql.org/file/comm..._datatypes.pdf

[IBExpert]

innerhalb zB der Euro Welt oder beim US$ kommt man mit fest defininerten 2 Nachkommastellen eigentlich schon ganz gut klar im Bereich Währungsangaben, bei Mengenangaben ist das je nach Branche und Mengeneinheit aber schon ganz anders. Im Bereich industrieller Kalkulation sind da schon gerne mal 3-4 Nachkommastellen erforderlich, daher ist eigentlich Numeric(18,4) schon der passende Typ (der war aber pysikalisch im Dialekt 3 in einem Bigint gespeichert.

Vielleicht hilft es dir aber, einfach mal auch in Firebird den Typ "DOUBLE PRECISION" zu nehmen, dessen Verhalten ziemlich identisch zum Double in Delphi ist.
Um den dann mit definierter Anzahl Nachkommastellen darzustellen, kannst du dir ja bei Firebird 3 eine eigene Stored function bauen, die deine Währungseinstellung berücksichtigt oder konstant einfach mit ROUND() oder cast arbeiten

[Olli73]

Ich hatte mir mal per UDF Funktionen angelegt, die das casten vereinfachen:

roundC4 = Runden auf 4 Nachkommastellen
CuToDp = Currency to Double Precision
etc.

Aussehen tut das dann so:

Code:

B_SPROZ   = case when B_SND=0 then 0 else roundc4(cutodp(1200)/cutodp(B_SND)) end,

oder so:

Code:

B_SAFAWJ  = case when 
              B_SRND=0 
            then 
              roundc2( cutodp(0) + cutodp(B_ZUGWJ) )
            else 
              case when 
                B_WJAHR=B_IJAHR
              then 
                roundc2( cutodp(B_ZUGWJ)*cutodp(13-B_ZUGMON)/cutodp(B_SRND) ) 
              else 
                roundc2(   
                  case when 
                    B_SRND<=12
                  then 
                    cutodp(B_SRWVJ)*cutodp(B_AWERT-B_ABGWJ)/cutodp(B_AWERT) 
                    + cutodp(B_ZUGWJ)
                  else 
                    cutodp(B_SRWVJ)*cutodp(B_AWERT-B_ABGWJ)/cutodp(B_AWERT) * cutodp(12)/cutodp(B_SRND) 
                    + cutodp(B_ZUGWJ)*cutodp(13-B_ZUGMON)/cutodp(B_SRND-B_ZUGMON+1) 
                  end
                )
              end 
            end,

Edit: Mit Oracle z.B. gibt es diese Probleme nicht.

[MyRealName]

Zitat von IBExpert:

Vielleicht hilft es dir aber, einfach mal auch in Firebird den Typ "DOUBLE PRECISION" zu nehmen, dessen Verhalten ziemlich identisch zum Double in Delphi ist.
Um den dann mit definierter Anzahl Nachkommastellen darzustellen, kannst du dir ja bei Firebird 3 eine eigene Stored function bauen, die deine Währungseinstellung berücksichtigt oder konstant einfach mit ROUND() oder cast arbeiten

Hat Double Precicion nicht das gleiche Problem wie die anderen "natürlichen" floats, dass 0 nicht gleich 0 ist ?
Eins der probleme, welche ch immer wieder habe ist das physikalisch meine Inventarmenge 0 ist, aber beim Berechnen in firebird sowas wie 0.00000046784345 rauskommt, und das dann ich Berechnungen zu riesig grossen zahlen führt, die einen überlauf produzieren..

[Lemmy]

Zitat von MyRealName:

http://www.firebirdfaq.org/faq79/

Zitat:

Here's an example: if you multiply 9.12 with 8.11 (both numeric(18,2)) you would get 73.9632. If Firebird would store that into numeric(18,2) datatype, we would lose 0.0032. Doesn't look much, but when you have complex calculations, you can easily loose thousands (dollars or euros). Therefore, the result is stored in numeric(18,4).

ähm. ja.. Logisch. Technisch bedingt aber eine Multiplikation von Numeric(18,4) kein Ergebnis mit mehr Nachkommastellen. Das kann max. eine fachliche Anforderung sein, davon hast Du leider nix geschrieben. Und ja, es gibt Anwendungsfälle, bei denen man zwingend die Zwischenergebnisse auf 2 Nachkommastellen rundet.