MSSQL und Datumsformat

[Jelly]

Ich bin grad dabei einen Server umzuswitchen, und hab jetzt den SQL Server 2000 installiert, allerdings diesmal eine deutsche Version. Seitdem funktionieren aus PHP heraus z.B. solche Abfragen nicht mehr:

SQL-Code:

insert into Tabelle (datum) values ('2006-07-17 20:00:00')

nicht mehr. Der Server meckert, es gäbe Probleme bei der Konvertierung von Char nach Datetime:

Server: Nachr.-Nr. 242, Schweregrad 16, Status 3, Zeile 1
Bei der Konvertierung eines char-Datentyps in einen datetime-Datentyp liegt der datetime-Wert außerhalb des gültigen Bereichs.
Die Anweisung wurde beendet.
Weil ich nicht jetzt überall im Programm aus 2006-07-17 einen 17.07.2006 setzen möchte, suche ich nach einer Möglichkeit, dies am SQL Server direkt zu konfigurieren...

Aber ich werd nicht fündig :wall:

[Bernhard Geyer]

Kannst du nicht bei PHP aus parametrisierte Abfragen verwenden? Dann ist dir das Displayformat von Datumswerten Schnurz-Piep-Egal.

[Jelly]

Das Ganze ist mir einfach zu aufwendig. Wenn ich dieses Datumformat direkt am SQL Server wechseln könnt, dann hätt ich mit keiner Applikation irgendwelche Probleme. Es geht nicht nur um 3 PHP Seiten, sondern auch um mehrere Delphi Anwendungen, einige sogar von denen ich nicht mal den Source hab.

[Union]

Das sollte gehen mit

SQL-Code:

SET DATEFORMAT ymd

[Christian Seehase]

Moin Tom,

das hatte ich auf einem MS SQL Server 2000 auch mal.
Der war nur durch die Sprachangabe im Connectstring dazu zu überreden, das Datumsformat zu akzeptieren.

Das war eine Datenbank, die durch Backup und erzwungenen Restore in eine andere entstanden ist.
In der ursprünglichen lief es ohne Sprachangabe :gruebel:

[jensw_2000]

oder alternativ

SQL-Code:

insert into Table (Datum) values ( CONVERT(DATETIME,'2006-07-17 20:00:00',120) )

Informationen zu den Formattierungs-Codes findest du hier im MSDN unter der Überschrift "Datentypen in SQL Server 2000"



Schöne Grüße,
Jens
:hi:

[Peinhard]

Union hat SET DATEFORMAT ja schon erwähnt. Sollten noch andere Einstellungen betroffen sein bzw einige Programme von einer komplett englischen Installation ausgehen, würde ich mir auch den sozusagen 'übergeordneten' Befehl SET LANGUAGE ansehen. Übergeordnet deshalb, weil er SET DATEFORMAT eben auch gleich 'in diesem Sinne' miterledigt. Diese Einstellungen sind allerdings temporär und auf die jeweilige Sitzung beschränkt, dh können bzw müssen zur Ausführungs- bzw Laufzeit immer neu gesetzt werden (eine Applikation sollte das daher entsprechend selbst einsetzen um sicherzustellen, daß Annahmen eben zB über das Datumsformat auch zutreffen). Für eine 'dauerhafte' Einstellung siehe 'default language' bzw 'sp_defaultlanguage' in der OLH, das dürfte für deine Belange und nach deiner Schilderung hier erstmal das Mittel der Wahl sein. Mittelfristig würe ich aber auch zumindest alle Programme unter eigener Regie entsprechend mit den SET-Befehlen ausstatten und wenn möglich auch die Hersteller der Fremdprogramme darauf hinweisen. Dann kann es einem egal sein, auf welche Sprachversion der/die Server eingestellt ist/sind.

[Jelly]

Moijn zusammen,

sorry, wurd bischen spät gestern abend, kam nicht mehr zum Testen...

SQL-Code:

EXEC sp_defaultlanguage 'MeineDomain\Domänen-Benutzer', 'english'

so wie von Peinhard vorgeschlagen, scheint bei mir zu klappen.

Vielen Dank, das hat meinen grauen Haarwuchs jetzt doch wieder etwas gemildert :thumb:

[Union]

Hi Jelly,

alternativ geht auch dies

SQL-Code:

EXEC sp_configure 'defaultlanguage', 1033

dann braucht man es nie wieder zu setzen.

[Jelly]

Mit

SQL-Code:

EXEC sp_defaultlanguage

schein ich es aber auch nicht mehr setzen zu müssen, oder ? Wann würde die Sprache denn resettet werden, bei einem SQL Server Neustart?

[Union]

Die Sprache wird nicht resetted. Es gilt die Sprache die beim Server konfiguriert ist (mit sp_configure und reconfigure) oder die des Users oder der Gruppe (mit sp_defaultlanguage) oder die eines bestimmten SQL-Server-Users (mit sp_addlogon).

Für eine systemweite Einstellung für alle User und Gruppen ist IMHO sp_configure am Besten. Bei dem Einsatz über PHP sollte es aber normalerweise immer der gleiche User sein, es sei denn Du machst auch eine entsprechende Authentifzierung.

[Jelly]

Danke, jetzt habs ichs geblickt :zwinker: