Datumsangaben in SQL Queries sind immer wieder eine Freude. Im Gegensatz zu allen anderen Datentypen hat man es hier auch noch mit einer sprachspezifischen Einstellung (US English, Deutsch etc.) zu tun.
Also was macht der Entwickler, er schreibt SQL Code wie diesen, der die Funktion CONVERT oder CAST verwendet:
CREATE VIEW dbo.International_Dates AS
SELECT PurchaseOrderID, TotalDue
FROM AdventureWorks.Purchasing.PurchaseOrderHeader
WHERE OrderDate < CONVERT(DATETIME,'2002.05.01',102);
Man kann eben nicht sicher sein wie der Datumswert interpretiert wird. Das folgende Statement würde also nur mit einer englischen Locale funktionieren:
CREATE VIEW dbo.USA_Dates AS
SELECT PurchaseOrderID, TotalDue
FROM AdventureWorks.Purchasing.PurchaseOrderHeader
WHERE OrderDate < 'May 1, 2002';
Dabei gibt es ein Datmsformat im MS-SQL Server, dass immer gleich interpretiert wird, das so genannte Unseparated String Format . Netterweise geht das sogar für DateTime Werte wenn man diesen im Format yyyyMMdd hh:mm:ss.ttt angibt.
Dies entspricht den CAST/CONVERT Formaten 112 und 114!
Man kann den obigen Query also komplett locale-unabhängig so schreiben.
CREATE VIEW dbo.Uniform_Date AS
SELECT PurchaseOrderID, TotalDue
FROM AdventureWorks.Purchasing.PurchaseOrderHeader
WHERE OrderDate < '20020501';
Man kann sich CAST und CONVERT also oft genug sparen wenn man Queries aufbaut, da Datum-Strings im Format yyyyMMdd hh:mm:ss.ttt, eben sprach/localeunabhängig sind.
Ich habe eine spezielle Funktion die genau dieses MS-SQL-Format benutzt um ein COleDateTime in das entsprechende Stringformat für einen SQL Query zu bringen, wenn ich mal keine Parameter in einem Query benutzen will oder kann.
Nachtrag: es ist ohne Probleme möglich die Uhrzeit auch abgekürzt zu übergeben, wie z.B. auch in der Form: yyyyMMdd hh:mm, oder yyyyMMdd hh:mm:ss ❗
Lustig, genau vor dem Problem stand ich gestern auch.
Ist denn sicher dass das auch mit der Uhrzeit im Format hh:mm:ss.ttt funktioniert? In dem Dokument steht doch nur wie das mit dem Datum oder einer Uhrzeit funktioniert, aber nicht genau welches Format die Uhrzeit haben muss.
Ja! Das ist sicher. Ich verwende diese Methodik seit Jahren. Man kann die Uhrzeit aber auch beliebig abkürzen. D.h. man kann auch nur hh:mm übergeben oder eben hh:mm:ss!
Das habe ich vergessen zu schreiben.
Laut BOL2005 ist Format 113 aber dieses:
13 oder 113 Europ. Standard + Millisekunden „dd mon yyyy hh:mi:ss:mmm“ (24h)
und 112 ist nur Datum nach ISO.
Wie müßte der String bei Datum und Zeit aussehen? So?
‚20090310 12:34:56.789‘
Geht auch?
‚20090310 12:34‘
Upps. Das Zeitformat ist nicht 113 sondern 114!
Ich habe den Artikel entsprechend korrigiert.
Und ja es geht auch ‚20090310 12:34‘ Siehe Kommentar zuvor.
Auf welchen Fehler sprichst Du an?
Mit SET DATEFORMAT kann die Reihenfolge der Datumsbestandteile (Jahr, Monat, Tag) angegeben werden. Dann können Datumsfeldzuweisungen und -vergleiche in einem vom Programmierer bestimmten Format vorgenommen werden, ohne auf „Standardformattricks“ zugreifen zu müssen.
@Martin Grotegut:
Was sind daran “Standardformattricks”?
Es ist dokumentiert und seit SQL 6x drin.
Warum soll ich ein extra SQL-Statement senden, oder eine Funktion verwenden um zu sagen was ich meine, wenn es einen dokumentierten Syntax für Datum und Zeit gibt, der immer gleich verstanden wird?
http://msdn.microsoft.com/en-us/library/ms187085(SQL.90).aspx
http://msdn.microsoft.com/en-us/library/ms187642(SQL.90).aspx