Datenqualität in SQL Server // TRY_CONVERT für date, datetime, datetime2 und time sicher anwenden

Wer einmal eine CSV-Spalte mit gemischten Datums-Formaten in eine datetime-Spalte importieren musste, weiß: Datenqualität beginnt bei der Typ-Konvertierung. SQL Server lässt einen mit style-Codes alleine, sobald das Format vom Standard abweicht — TRY_CONVERT deckt die dokumentierten Formate ab, alles andere braucht eine eigene Funktion. Das nimmst du mit: Voraussetzung: SQL Server 2017+ (für TRY_CONVERT-Styles 23/126), für die Postgres-Brücke PostgreSQL 12+. Inhalt Überblick Die wohl herausforderndste Konvertierung … Weiterlesen

Datenqualität in SQL Server // TRY_CONVERT für bit sicher anwenden — Ja/Nein-Werte konvertieren

Datenqualität beginnt bei der Typ-Konvertierung — und bei bit-Spalten zeigt sich das schon beim Eingangswert: Yes/No-Informationen liegen in Legacy-Quellen in unterschiedlichsten Notationen vor (‚J‘, ‚Y‘, ‚ON‘, ‚1‘, ‚x‘, ‚-‚, …). SQL Servers eingebautes TRY_CONVERT(bit, …) deckt nur den Ziffern-Standard plus ‚true’/’false‘ ab — alles andere braucht eine eigene Konvertierungs-Funktion. Dieser Artikel beschreibt beides: was eingebaut funktioniert, wann eine fn_convert_bit-Funktion her muss und wie das Pendant in Postgres … Weiterlesen

Datenqualität in SQL Server // TRY_CONVERT für float und real sicher anwenden

Datenqualität bei Gleitkomma-Spalten ist eine eigene Disziplin — und TRY_CONVERT(float, …) hat ein paar Eigenheiten, die im Import-Pfad gerne übersehen werden: eine leere Zeichenfolge wird zu 0 (statt zu NULL), ein Komma als Dezimaltrennzeichen führt zu NULL, und selbst nach einer sauberen Konvertierung ergibt 2 + 3.4 – 3.4 – 2 als float nicht exakt 0. Dieser Artikel sortiert die Regeln, zeigt das sichere Konvertierungs-Pattern und macht … Weiterlesen

Datenqualität in SQL Server // TRY_CONVERT für money und smallmoney sicher anwenden

Wer einmal einen Kassen-Report mit Werten wie ‚1.234,56 €‘ aus einer CSV in eine SQL-Server-Datenbank importieren musste, kennt das Muster: TRY_CONVERT(money, ‚1,234.56‘) liefert 1234.5600. Doch TRY_CONVERT(money, ‚1.234,56‘) liefert NULL. Und selbst wenn der Import sauber läuft: money / 100 * 100 ist nicht zwangsläufig dasselbe wie der Ausgangswert. Kurzüberblick — was dieser Artikel klärt: Voraussetzung: SQL Server 2017+ (für TRIM im sicheren Pattern; vor 2017 als LTRIM(RTRIM(…))-Fallback). Kein Sample-Datensatz nötig … Weiterlesen

Datenqualität in SQL Server // TRY_CONVERT für decimal und numeric sicher anwenden

Wer einmal einen Preis-Import gesehen hat, der aus ‚123,45 €‘ ein NULL macht statt der erwarteten Dezimalzahl, weiß: TRY_CONVERT(decimal(5, 2), ‚123,45‘) liefert NULL, weil das Komma als Dezimaltrennzeichen nicht erlaubt ist. Und selbst wenn das Komma weg ist: TRY_CONVERT(decimal(5, 2), ‚1234.56‘) ist auch NULL — diesmal wegen einer Vorkomma-Stelle zu viel. Auf einen Blick: Voraussetzung: SQL Server 2017+ (TRIM im sicheren Pattern; vor 2017 LTRIM(RTRIM(…))-Fallback). Postgres 12+ für … Weiterlesen

Datenqualität in SQL Server // TRY_CONVERT für bigint, int, smallint und tinyint sicher anwenden

Datenqualität beginnt bei der Typ-Konvertierung — und bei Integer-Spalten zeigt TRY_CONVERT ein paar Eigenheiten, die im Import-Pfad gerne übersehen werden: eine leere Zeichenfolge wird zu 0 (statt zu NULL), jedes Dezimal- oder Tausendertrennzeichen führt zu einem NULL, und eine typisierte Dezimalzahl wird stillschweigend abgeschnitten — ohne Rundung. Dieser Artikel sortiert die Regeln, zeigt das sichere Konvertierungs-Pattern und reicht eine Postgres-Brücke nach. Kurzüberblick: … Weiterlesen