2012-05-30 13 views
6

Ich habe viele Schwierigkeiten mit der Ländereinstellung in einer bestimmten Instanz von SQL Server 2008 R2 Express.Fehler beim Konvertieren der Zeichenfolge in "datetime" aufgrund der Ländereinstellung

ich in Großbritannien bin und die folgenden nicht:

SELECT CAST('2012-12-31' AS DATETIME) 

Fehlermeldung:

Die Umwandlung einer varchar-Datentyp auf einen Typ Datetime-Daten führte zu einer Out-of Bereichswert.

Das Windows-Servergebietsschema ist Britisches Englisch. Mein Login-Gebietsschema ist Britisches Englisch. Die Sortierung "wenn das zählt" ist Latin1_General_CI_AS.

Die Datenbank 'Sprache' ist Englisch (USA), aber dann ist dies die gleiche wie eine andere Instanz auf einem anderen Server und die obige SQL schlägt nicht fehl.

Irgendwelche Gedanken?

Antwort

8

Für die Benutzer, der die Datenbankverbindung herstellt - der SQL-Benutzer - stellt die Sprache auf Englisch ein.

Dies ist eine Einstellung speziell für den SQL-Benutzer der Verbindung die Ausgabe der Abfrage

Eine Möglichkeit, zu überprüfen, ob dies ein Problem ist ... Führen Sie dies in Management Studio und melden Sie sich als SQL-Benutzer, der die Abfrage ausgibt

SET LANGUAGE English 
SELECT CAST('2012-12-31' AS DATETIME) 

Wenn dies funktioniert, stellen Sie die Standardsprache des SQL-Benutzer in geeigneter Weise

+1

Ich stimme nicht zu, dass die Lösung darin besteht, allen Benutzern die gleiche Sprache zu geben. Was, wenn ihre Sprache absichtlich eingesetzt wird, weil sie für andere Dinge verwendet wird? Das Reparieren jedes Benutzers ist ebenfalls mühsam, da jedes Mal, wenn ein neuer Benutzer erstellt wird, der Code möglicherweise nur für sie versagt, bis Sie ihn behoben haben. Wenn Sie den Code reparieren, beheben Sie das Problem. –

+0

Dies ist nicht für alle Benutzer. Dies ist für ein SQL-Login-Konto – jglouie

+0

Ja, und wenn Sie ein neues SQL-Login-Konto hinzufügen und ihre Sprache auf Britisch eingestellt ist, raten Sie, was Ihr Code wieder zu tun beginnt? –

2

Sie sollten das Datumsformat auf Ihrem convert explizit definieren, in diesem Fall 120:

SELECT CONVERT(DATETIME,'2012-12-31',120) 

Sie einen Blick auf diese Seite nehmen können weitere Datumsformate zu sehen: http://msdn.microsoft.com/en-us/library/ms187928.aspx

+0

Das Problem wird dies soll eine exakte Nachbildung eines Live sein System. Das Live-Setup funktioniert tatsächlich und scheint die gleiche Konfiguration zu verwenden. Mir ist klar, dass ich das übertragen kann, aber ich kann das gespiegelte System nicht ändern. – Dillorscroft

6

nicht YYYY-MM-DD für Datumsliterale verwenden Sie immer YYYYMMDD verwenden. Das wird nie, und zwar unabhängig von locale fehl, Datumsformat, Sprachen-, regionale Einstellungen, etc:

SELECT CAST('20121231' AS DATETIME); 

Ein lohnender Lese vielleicht: http://sqlblog.com/blogs/aaron_bertrand/archive/2009/10/16/bad-habits-to-kick-mishandling-date-range-queries.aspx

+0

und was passiert, wenn Ihr Benutzer ein Datum als YYYYDDMM speichert? sql wird es nie wissen, und Sie werden mit Lastwagen voller Fehler konfrontiert, die schwer zu lokalisieren sind. viel sicherer zu konvertieren mit Datumsformat wie Lamak sagte. –

+2

@Thierry Wenn ein Benutzer "20121208" als eindeutigen Standard übergibt und sie den 12. August statt 8. Dezember bedeutet, wird das falsche Datum gespeichert. Wenn sie "20121612" übergeben, erhalten sie einen Fehler. Das sind genau die gleichen Dinge, die passieren, wenn Ihr Benutzer '' 2012-12-08 '' zu Lamaks Methode übergibt. Der Unterschied ist, dass JJJJMMTT * immer * von SQL Server so interpretiert wird, während JJJJ-MM-TT * manchmal * falsch interpretiert wird. –

+0

Ich sehe, danke für die Info. Ich frage, weil, wo ich arbeite, ist die regionale Einstellung YYYYDDMM, weil wir es unseren Kunden erzwingen, aber die lokale Einstellung standardmäßig DDMMYYYY, und es führt oft zu Verwirrungen auf Daten. –

Verwandte Themen