T-SQL: TRY_PARSE() – Die Hilfe für internationalisierte Daten

Jeder, der mit Daten aus Fremdsystemen arbeitet, hat sicher schon mal Probleme mit der Konvertierung in das korrekte Datenformat gehabt. Dieses ist ein sehr mühseliges Unterfangen, wenn man nicht genau weiß, in welchem Datenformat die Quelldaten ankommen.

Gerade bei dem Datentyp money gibt es immer wieder Probleme. Das kommt daher, dass sich zum Beispiel die Punkt- und Komma-Notation in Deutschland und dem amerikanischen Raum unterscheidet.

In Deutschland trennen wir die Tausender-Stellen mit Punkt und die Nachkommastelle mit einem Kommata. Im amerikanischen Raum ist dieses genau umgekehrt.

Beispiel ausgehend von einem amerikanischen System:

-- Wird konvertiert in 1000,10:
SELECT CAST('1,000.1' as money) 
-- Wird konvertiert in 1,0001:
SELECT CAST('1.000,1' as money) 

Ein Problem entsteht nun, wenn man eine Ladekette entwickelt, die beide Fälle abdecken soll. Denn der CAST-Funktion ist es egal, wie rum der Punkt und das Komma steht und konvertiert es immer erfolgreich. Seit der Version des Microsoft SQL Server 2012 gibt es dafür eine einfache Lösung. Eine neue Funktion namens TRY_PARSE() wurde veröffentlicht, welche es ermöglicht, mit einem Culture Code in das gewünschte Format zu konvertieren. Schlägt die Konvertierung fehl, dann wird NULL zurückgegeben.

Beispiel ausgehend von einem amerikanischen System:

-- Wird konvertiert in 1000,10:
SELECT TRY_PARSE('1,000.1' as money using 'en-us') 
-- Wird konvertiert in NULL:
SELECT TRY_PARSE('1.000,1' as money using 'en-us') 

Anders als im vorherigen Beispiel wird keine fehlerhafte Konvertierung angewendet, sondern ein NULL-Wert zurückgegeben, wenn der eingegebene Wert mit dem Culture Code nicht plausibel ist.

Die TRY_PARSE() Funktionalität kann nun mit ISNULL() gekoppelt werden.

Beispiel ausgehend von einem amerikanischen System:

SELECT ISNULL(
  TRY_PARSE('1,000.1' as money using 'de-de'), 
  TRY_PARSE('1,000.1' as money using 'en-us')
) -- gibt immer 1000,10 zurück

Nun haben wir eine Möglichkeit geschaffen, dass der Wert immer korrekt importiert werden kann, denn es kommt immer der richtige Wert zurück, ganz gleich, ob die Quelldaten das deutsche oder das amerikanische Format aufweisen.

TRY_PARSE() unterstützt nahezu alle Numeric und Datetime – Datentypen, die der Microsoft SQL Server mitbringt.

Zum Beispiel kann auch so kontrolliert werden, in welchem Datenformat die Daten geliefert wurden.

Beispiel ausgehend von einem amerikanischen System:

-- Gibt aus 'Kein DE-Datum':
SELECT IIF(
  TRY_PARSE('01/31/2015' as date using 'de-de') IS NULL, 
  'Kein DE-Datum', 
  'DE-Datum') 
-- Gibt aus 'DE-Datum':
SELECT IIF(
  TRY_PARSE('31.01.2015' as date using 'de-de') IS NULL, 
  'Kein DE-Datum', 
  'DE-Datum') 

Dieses funktioniert auch mit explizitem Setzen der Sprache und ohne Culture Code:

-- Gibt aus 'nicht konvertiert':
SET LANGUAGE ENGLISH;
SELECT IIF(
  TRY_PARSE('31.01.2015' as date) IS NULL, 
  'nicht konvertiert', 
  'konvertiert') 

-- Gibt aus 'konvertiert'
SET LANGUAGE GERMAN;
SELECT IIF(
  TRY_PARSE('31.01.2015' as date) IS NULL, 
  'nicht konvertiert', 
  'konvertiert') 

Ich hoffe, dass Euch diese kurze Einführung in den oft nicht beachteten oder (noch nicht) bekannten Befehl aus dem T-SQL-Bereich gefallen hat.

Über Feedback und Diskussion in den Kommentaren freue ich mich immer.

Haben Sie Fragen zu diesem Artikel oder brauchen Sie Unterstützung?

Nehmen Sie mit uns Kontakt auf!

Wir unterstützen Sie gerne bei Ihren Vorhaben!