AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken MS SQL Genauigkeit in der Termauswertung

MS SQL Genauigkeit in der Termauswertung

Ein Thema von TigerLilly · begonnen am 12. Jun 2019 · letzter Beitrag vom 13. Jun 2019
Antwort Antwort
Seite 2 von 4     12 34   
TigerLilly

Registriert seit: 24. Mai 2017
Ort: Wien, Österreich
543 Beiträge
 
Delphi 10.3 Rio
 
#11

AW: MS SQL Genauigkeit in der Termauswertung

  Alt 12. Jun 2019, 15:09
Ja, so erhalte ich das erwartete Ergebnis. Wir haben eine Tabelle mit Formeln, die vom SQL Server ausgewertet werden + ich bin sehr sehr sicher, dass das früher anders funktioniert hat. Der 2008R2 ist schon Jahre im Einsatz + das Problem ist jetzt erst aufgepoppt.

Wir werden wohl in allen Formeln die Skalare mit .0 ergänzen.
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
2.600 Beiträge
 
Delphi 2010 Enterprise
 
#12

AW: MS SQL Genauigkeit in der Termauswertung

  Alt 12. Jun 2019, 15:53
keine Ahnung ob diese Beobachtung nun so ist wie sie ist, aber wenn, dann:
Mal bei MS nachschlagen, solche Änderungen werden eigentlich nicht "einfach so" mal ins Feld geworfen. Es müsste dazu Migrationshinweise geben und normalerweise auch Schalter, die das (alte) Verhalten bewahren, forcieren usw.

Kommt natürlich bei der Art der Anpassung auf das zu erwartende Änderungesvolumen an und wie exakt man die Problemstellung überhaupt finden kann.
Gruß, Jo
  Mit Zitat antworten Zitat
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
7.216 Beiträge
 
Delphi XE4 Professional
 
#13

AW: MS SQL Genauigkeit in der Termauswertung

  Alt 12. Jun 2019, 16:08
Hallo,
hm, also hier

https://docs.microsoft.com/en-us/pre...v%3dsql.110%29

steht

The precision and scale of the numeric data types besides decimal are fixed. If an arithmetic operator has two expressions of the same type, the result has the same data type with the precision and scale defined for that type.

Und weiter unten ist noch eine Tabelle.

Das war also schon immer so, zumindestens beim 2012-er
Heiko
  Mit Zitat antworten Zitat
TigerLilly

Registriert seit: 24. Mai 2017
Ort: Wien, Österreich
543 Beiträge
 
Delphi 10.3 Rio
 
#14

AW: MS SQL Genauigkeit in der Termauswertung

  Alt 12. Jun 2019, 16:09
Vielleicht ist das bei uns auch einfach durchgerutscht und die Erinnerung siegt über Tatsachen. Oder - wie es so schön heisst: Die Wahrheit ist eine Tochter der Zeit.

Das Problem gibt es wahrscheinlich auch nur, wenn man das SQL Statement als Text zusammenbaut, sonst hat man eh Paramter und passende Datentypen.

Aber zum Merken: <int> <op> <int> liefert <int>.
  Mit Zitat antworten Zitat
Delphi.Narium

Registriert seit: 27. Nov 2017
1.093 Beiträge
 
Delphi 7 Professional
 
#15

AW: MS SQL Genauigkeit in der Termauswertung

  Alt 12. Jun 2019, 16:31
Delphi und ADO:
SQL-Code:
select 12/100*0.5 from dual; => 0
select 0.5/100*12 from dual; => 0

select 0.1*(12/100*0.5) from dual; => 0
select 0.1*(0.5/100*12) from dual; => 0

select (12/100)*0.5 from dual; => 0
select (0.5/100)*12 from dual; => 0

select 0.1*(12/100)*0.5 from dual; => 0
select 0.1*(0.5/100)*12 from dual; => 0
FlameRobin
SQL-Code:
select 12/100*0.5 from dual; => 0,0
select 0.5/100*12 from dual; => 0,0

select 0.1*(12/100*0.5) from dual; => 0,00
select 0.1*(0.5/100*12) from dual; => 0,00

select (12/100)*0.5 from dual; => 0,0
select (0.5/100)*12 from dual; => 0,0

select 0.1*(12/100)*0.5 from dual; => 0,00
select 0.1*(0.5/100)*12 from dual; => 0,00
Interessant finde ich, das die Anzahl der Nachkommastellen im Ergebnis jedesmal der Summe der Nachkommastellen in der Rechnung Entspricht.
Nein, das ist nicht interessant, haben wir schon in der Schule gelernt: Wenn man zwei Zahlen mit Nachkommastellen multipliziert, so erhält man im Ergebnis soviele Nachkommastellen, wie die multiplizierten Zahlen zusammen enthalten.

Zwei Nachkommastellen * zwei Nachkommastellen = 4 Nachkommastellen.

https://de.bettermarks.com/mathe/mul...dezimalzahlen/

Ok, wenn man sich das Ergebnis über FlameRobin anschaut, so stimmt das, die Regel wird eingehalten.

Über Delphi und ADO werden die Nachkommastellen (bei Beachtung der Regel) jedoch nur ausgegeben, wenn sie <> 0 sind.

Taschenrechner & Co. scheinen da etwas "flexibler" zu sein, sie erweitern die Nachkommastellen implizit, wenn es für eine korrekte Darstellung des Ergebnisses erforderlich scheint.

Fazit: Rechnen über Select nur, wenn man sich der Einhaltung dieser Regel bewusst ist.
  Mit Zitat antworten Zitat
TigerLilly

Registriert seit: 24. Mai 2017
Ort: Wien, Österreich
543 Beiträge
 
Delphi 10.3 Rio
 
#16

AW: MS SQL Genauigkeit in der Termauswertung

  Alt 12. Jun 2019, 18:56
Du machst die Sache kompliziert, denn hier geht es um MS-SQL Server. DUAL gibt es für den nicht und wie ich beschrieben habe, sind die Ergebnisse andere:

select 12/100*0.5 --> 0
select 0.5/100*12 --> 0,06
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.390 Beiträge
 
Delphi 7 Personal
 
#17

AW: MS SQL Genauigkeit in der Termauswertung

  Alt 12. Jun 2019, 21:03
Von einer nicht ganz kleinen DB bin ich es gewohnt,daß ich für jeden numerischen Wert das gewünschte Ausgabeformat definiert habe. Und das hat ganz gut funktioniert.
Mit irgendwelchen Seiteneffekten zu rechnen ohne daß mich jemand für meine Genialität feiert war mir auf Dauer zu anstrengend.

Gruß
K-H
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
TigerLilly

Registriert seit: 24. Mai 2017
Ort: Wien, Österreich
543 Beiträge
 
Delphi 10.3 Rio
 
#18

AW: MS SQL Genauigkeit in der Termauswertung

  Alt 13. Jun 2019, 07:02
Verstehe ich nicht. Was meinst du damit?
  Mit Zitat antworten Zitat
Benutzerbild von Moombas
Moombas

Registriert seit: 22. Mär 2017
Ort: bei Flensburg
256 Beiträge
 
Delphi 10.3 Rio
 
#19

AW: MS SQL Genauigkeit in der Termauswertung

  Alt 13. Jun 2019, 07:21
Interessant finde ich, das die Anzahl der Nachkommastellen im Ergebnis jedesmal der Summe der Nachkommastellen in der Rechnung Entspricht.
Nein, das ist nicht interessant, haben wir schon in der Schule gelernt: Wenn man zwei Zahlen mit Nachkommastellen multipliziert, so erhält man im Ergebnis soviele Nachkommastellen, wie die multiplizierten Zahlen zusammen enthalten.
Jaein, denn: Nimmst du 0,1*0,1 stimmt die Aussage (=0,01) ABER: nimmst du 0,1*1,0 wäre das korrekte Ergebnis 0,1 (die nachstehenden Nullen sind irrelevant, da 0,1 = 0,10).
Und warum das in DIESEM Fall durchaus interessant ist: Das Ergebnis der Rechnung wäre 0,006 (3 Nachkommastellen), wenn nun aber in der Rechnung (0.1 * (0.5 / 100 * 12)) nur 2 Nachkommastellen vorkommen und daher davon ausgegangen wird, das man nur 2 Nachkommastellen braucht ist das Ergebnis logischerweise Falsch!
Folglich müsste man generell mit der maximal möglichen Anzahl an Kommastellen rechnen um einigermaßen vernünftig rechnen zu können (und keine Angst haben muss, das dadurch Kommastellen schlichtweg gestrichen werden). Daher:
0.1 * (0.5 / 100 * 12) = 0.00
0.1 * (0.50 / 100 * 12) = 0.006 (?)

@Tigerlilly:
Du machst die Sache kompliziert, denn hier geht es um MS-SQL Server. DUAL gibt es für den nicht und wie ich beschrieben habe, sind die Ergebnisse andere:

select 12/100*0.5 --> 0
select 0.5/100*12 --> 0,06
Was ist denn das Ergebnis wenn du folgende Rechenoperationen ausführst:
select (12/100)*0.5 --> ?
select 12/100*0.50 --> ?
Der Weg ist das Ziel aber man sollte auf dem Weg niemals das Ziel aus den Augen verlieren.

Geändert von Moombas (13. Jun 2019 um 07:32 Uhr)
  Mit Zitat antworten Zitat
Schokohase

Registriert seit: 17. Apr 2018
971 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#20

AW: MS SQL Genauigkeit in der Termauswertung

  Alt 13. Jun 2019, 07:22
Nur damit wir alle auf dem gleichen Stand sind
SQL-Code:
select 1,12/100*0.5
union
select 2,0.5/100*12
union
select 3,0.1*(12/100*0.5)
union
select 4,0.1*(0.5/100*12)
union
select 5,0.1*12/100*0.5
union
select 6,0.1*0.5/100*12
ergibt auf dem MS SQL 2017 ausgeführt
Code:
1 - 0
2 - 0.06
3 - 0
4 - 0.006
5 - 0.006
6 - 0.006
Beispiel auf SQLfiddle

Warum also jetzt der Unterschied zwischen Zeile 3 und Zeile 5?

Ganz einfach:

Es wird in Zeile 3 erst der Wert in den Klammern berechnet, und der ergibt (wie man in Zeile 1 sehen kann) eben 0 und diese 0 mit 0.1 multipliziert ergibt weiterhin 0.

Das ist das ganze Geheimnis

PS
Der wirkliche Problemauslöser ist die Division von zwei Ganzzahlen 12/100. Es würde reichen eine davon als Fließkommazahl zu deklarieren. Also 12/100.0 oder 12.0/100.

Geändert von Schokohase (13. Jun 2019 um 07:29 Uhr)
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:50 Uhr.
Powered by vBulletin® Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2019 by Daniel R. Wolf