Decimal Type, Führende Null fehlt bei MS SQL

[hawkmaster]

Hallo zusammen,
Ich habe die gleiche Datenbank einmal in MySQL und in MS SQL.
Bei einer Abfrage ist mir heute aufgefallen, dass beim MSSQL Server bei Zahlen die führenden Nullen fehlen.

  
$Result = $DBO->prepare("SELECT systemid,location, systemprice, tcpipaddress FROM mysystem WHERE systemid  = :systemsid ") ;  
	$Result->bindParam(':systemsid', $systemsid);  
	$Result->execute();  
	$rowSystems = $Result->fetch(PDO::FETCH_ASSOC);  
	return $rowSystems;  

Ein var_dump für MySQL liefert

string(6) "0.0000"

das gleiche bei MS SQL
string(5) ".0000"

Wenn ich die Abfrage von Hand im SQL Server Management Studio mache, bekomme ich auch die führende Null zurück, also 0.0000

Ich habe schon in den PDO manuals gesucht und gegoogelt, wurde aber nicht fündig.

Hat hier jemand eine Idee?
vielen Dank und viele Grüße
hawk

[suit]

Hat hier jemand eine Idee?

Du verwechselst hierbei scheinbar, dass der Datentyp und die Darstellung miteinander nicht viel zu tun haben.

ob da jetzt 0.1, 0.100 oder .1 daherkommt ist völlig egal. Wenn du diese information in einer menschenlesbaren Form darstellen willst, musst du sie auch entsprechend formatieren.

Boolsche werten werden je nach System (und Sprache) auch als true/false, WAHR/FALSCH, 0/1, 1/-1, 0/-1 oder sonstwie ausgegeben.

Diese Faktoren kommen zudem am Client oder am Server zum Tragen - also aufpassen :)

[hawkmaster]

Hallo suit,

Du verwechselst hierbei scheinbar, dass der Datentyp und die Darstellung miteinander nicht viel zu tun haben.

Nein, ich glaube nicht das ich das verwechsle. Es ist definitiv so das der PDO Treiber für MSSQL hier falsche Werte zurückbringt.
Meine weitere Recherchen ergaben das es sich wohl um einen Bug im Treiber handelt.

http://social.msdn.microsoft.com/Forums/en-US/sqldriverforphp/thread/6cc6d0b4-4aec-4f29-9fa5-ad88417a6a30/
trotzdem danke für deine Hilfe

vielen Dank und viele Grüße
hawk

[Fred Furunkelstein 2012]

Es ist definitiv so das der PDO Treiber für MSSQL hier falsche Werte zurückbringt.

Nein! '0.1' und die alternative Schreibweise '.1' repräsentieren den gleichen Zahlenwert, nämlich 1/10. Ergo kann keine der Schreibweisen gegenüber der anderen falsch sein. Es ist Dein Job als Programmierer für eine ordentliche Darstellung zu sorgen.

Genau das versäumen letztendlich auch die "Programmierer" an der Stelle, wo Du glaubst, dass dort dort der angebliche Fehler bestätigt wird. Die verwenden nämlich eine unformatierte Dezimalzahl als String, konkret als Bezeichner eines Hashes und überlassen die (implizite) Umwandlung einem Treiber, was natürlich auf Grund der zahllosen Möglichkeiten, eine Dezimalzahl als String darzustellen, zu "unerwarteten" Ergebnissen führt.

Notwendig ist es also, die Dezimalzahl zu einem String zu konvertieren. Das geht schon bei der Abfrage.

[hawkmaster]

Hallo,

Danke erst mal für deine Hilfe.

Notwendig ist es also, die Dezimalzahl zu einem String zu konvertieren. Das geht schon bei der Abfrage.

Ja so habe ich es jetzt auch gemacht mit :

CAST(A.price AS char(10)) AS price

Es ist halt nur etwas verwirrend und "unschön", wenn mit MySQL und PDO die Werte "richtig" zurückkommen, nämlich mit 0.0000 und auch ältere MS SQL Treibern sich anders verhalten.

vielen Dank und viele Grüße
hawk

[suit]

Es ist halt nur etwas verwirrend und "unschön", wenn mit MySQL und PDO die Werte "richtig" zurückkommen, nämlich mit 0.0000 und auch ältere MS SQL Treibern sich anders verhalten.

Wie schon gesagt, besonders unter MSSQL spielen extrem viele Faktoren eine Rolle - und das hat nichts mit "alter Treiber" zu tun - es kann je nach Lokalisierung auch 0,000 zurückkommen.

[suit]

es kann je nach Lokalisierung auch 0,000 zurückkommen.

Nachtrag: 0,000 kann durch implizites Casting in einen String zurückkommen - der Wert ist immer noch derselbe :)

[hawkmaster]

Hallo suit,

danke nochmals für deine Hilfe.

Wie schon gesagt, besonders unter MSSQL spielen extrem viele Faktoren eine Rolle - und das hat nichts mit "alter Treiber" zu tun - es kann je nach Lokalisierung auch 0,000 zurückkommen.

Ich bin jetzt nicht so der MSSQL Experte. Habe eher Erfahrung mit MySQL.
Könnte es auch irgendwas mit der Server Installation zu tun haben?
Was genau meinst du mit "Lokalisierung"
Ich habe zum Testen den SQL Server 2008 Express installiert.

vielen Dank und viele Grüße
hawk

[suit]

Ich bin jetzt nicht so der MSSQL Experte. Habe eher Erfahrung mit MySQL.
Könnte es auch irgendwas mit der Server Installation zu tun haben?

Was genau meinst du mit "Lokalisierung"

Die "Sprache" - wenn du z.B. das Verhalten ist auf einem englischsprachigen System anders als auf einem deutschsprachigen.

Ich habe zum Testen den SQL Server 2008 Express installiert.

Das ist vollig unerheblich - wie Fred schon sagte: wenn du ein bestimmtes Format willst, nutze eine explizite Angabe, die implizite Angabe ist "willkürlich" und muss nicht unbedingt auf jedem System gleich sein - CAST und CONVERT sind hier die mittel der Wahl.

Das ist wie bei der Sortierreihenfolge: wenn du diese nicht gesondert als ORDER BY angibst ist die ausgabe willkürlich - idR. wird sie zwar in der "Reihenfolge der Eintragung der Daten" angezeigt, definiert ist das aber nicht - die Reihenfolge könnte sich bei jeder Abfrage willkürlich ändern - darum ist es wichtig, dass eben die Behandlung explizt angegeben wird, wenn es dir nicht sowieso egal ist.