{"id":1181,"date":"2024-02-18T20:39:45","date_gmt":"2024-02-18T19:39:45","guid":{"rendered":"https:\/\/staging.sql.marcus-belz.de\/?p=1181"},"modified":"2024-03-02T09:36:21","modified_gmt":"2024-03-02T08:36:21","slug":"grundlagen-der-typ-konvertierung-mit-t-sql","status":"publish","type":"post","link":"https:\/\/staging.sql.marcus-belz.de\/?p=1181","title":{"rendered":"Datenqualit\u00e4t \/\/ Grundlagen der Typ-Konvertierung mit T-SQL"},"content":{"rendered":"\n

Dieser Artikel geh\u00f6rt zu der Artikelserie Datenqualit\u00e4t in einem ETL-Prozess<\/a>, in der ein Design Pattern vorgestellt wird, das die extrahierte Daten pr\u00fcft, behandelt und schlechte Daten von der weiteren Verarbeitung ausschlie\u00dft. <\/p>\n\n\n\n

SQL Server stellt mit den T-SQL Funktionen CAST<\/a><\/strong>, CONVERT <\/strong><\/a>beziehungsweise TRY_CONVERT<\/a> <\/strong>und TRY_CAST<\/a> <\/strong>Funktionen f\u00fcr die Typ-Konvertierung zur Verf\u00fcgung. Die Syntax der Funktionen CONVERT <\/strong>und TRY_CONVERT <\/strong>beziehungsweise CAST<\/strong> und TRY_CAST<\/strong> ist identisch. Der Unterschied liegt einzig darin, dass TRY_CONVERT <\/strong>und TRY_CAST<\/strong> keine Exception werfen, wenn der \u00fcbergebene Wert nicht in den Zieldatentypen konvertiert werden kann. Die Funktionen geben im Fehlerfall ein NULL<\/em> zur\u00fcck. <\/p>\n\n\n\n

Zwischen den Funktionen CAST <\/strong>und CONVERT <\/strong>gibt es zwei wesentliche Unterschiede.<\/p>\n\n\n\n

Zum einen ist die Funktion CONVERT <\/strong>(und damit auch TRY_CONVERT<\/strong>) eine SQL Server spezifische Funktion und entspricht nicht dem ANSI SQL Standard<\/em>. In anderen Worten: Die Funktion CAST <\/strong>existiert in Oracle<\/em>, Postgres <\/em>und anderen Datenbanksystemen, die Funktion CONVERT <\/strong>mit einer \u00e4quivalenten Funktionsweise jedoch (m\u00f6glicherweise) nicht. Die Funktion TRY_CAST <\/strong>ist ebenfalls eine SQL Server spezifische Funktion.<\/p>\n\n\n\n

Zum anderen erlauben die Funktionen TRY_CONVERT<\/strong> und CONVERT<\/strong> im Gegensatz zu den Funktionen CAST <\/strong>und TRY_CAST<\/strong> die Angabe eines Style-Parameters, der von der Funktion f\u00fcr die Interpretation des \u00fcbergebenen Wertes verwendet wird. Ein Beispiel hierf\u00fcr ist ein Datum, das als Text an die Funktionen CAST <\/strong>oder CONVERT <\/strong>\u00fcbergeben wird. F\u00fcr das Datum gibt es in den L\u00e4ndern dieser Welt sehr unterschiedliche Schreibweisen. Das Datum 02.11.2024 <\/strong>(Deutsche Schreibweise) wird gem\u00e4\u00df der folgenden Tabelle sehr unterschiedlich notiert:<\/p>\n\n\n\n

Land<\/th>Formatstring<\/th>Datum<\/th>Style-Parameter<\/th><\/tr><\/thead>
Deutschland<\/td>dd.mm.yyyy<\/td>02.11.2024<\/td>104<\/td><\/tr>
USA<\/td>yyyy\/mm\/dd<\/td>11-02-2024<\/td>110<\/td><\/tr>
Japan<\/td>mm-dd-yyyy<\/td>2024\/11\/02<\/td>111<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Eine typsichere Konvertierung kann nur dann erfolgen, wenn wir Kenntnis \u00fcber das Datumsformat und den korrekten Style-Parameter haben. Die folgenden SELECT Statements verdeutlichen die Problematik:<\/p>\n\n\n\n

 1: SELECT CAST('02.11.2024' AS date);       -- > 2024-02-11\n 2: SELECT CAST('11-02-2024' AS date);       -- > 2024-11-02\n 3: SELECT CAST('2024\/11\/02' AS date);       -- > 2024-11-02\n 4: \n 5: SELECT CONVERT(date, '02.11.2024', 104); -- > 2024-11-02\n 6: SELECT CONVERT(date, '2024\/11\/02', 111); -- > 2024-11-02\n 7: SELECT CONVERT(date, '11-02-2024', 110); -- > 2024-11-02\n 8: \n 9: SELECT CONVERT(date, '02.11.2024', 111); \n10:  -- > Exception: Conversion failed when converting date and\/or \n11:  --              time from character string.<\/code><\/pre>\n\n\n\n

Die zur\u00fcckgegebenen Werte, die hinter den Kommentarzeichen notiert sind, wurden dem Resultset im SQL Server Management Studio <\/em>entnommen. Per Default wird ein Datum in dem Resultset in SQL Server Management Studio<\/em> – solange ein SQL Statement keine explizite Format-Anweisungen enth\u00e4lt – in amerikanischer Notation (also yyyy-MM-dd<\/strong>) ausgegeben. Demnach wird ein Deutsches Datum in Zeile 1<\/strong> von der Funktion CAST <\/strong>falsch interpretiert. Statt 02.11.2024<\/strong> erhalten wir als Ergebnis den 11.02.2024<\/strong>. Durch die Angabe des korrekten Style-Parameters 104 <\/strong>in Zeile 5<\/strong> in der Funktion CONVERT<\/strong>, kann aber auch ein Deutsches Datum korrekt interpretiert werden.<\/p>\n\n\n\n
Ohne an dieser Stelle genauer auf die Probleme bei der Typ-Konvertierung in Abh\u00e4ngigkeit von dem Datentyp einzugehen, sollte zwei Dinge klar sein:<\/p>\n\n\n\n