Datenqualität

Wer einmal eine Messreihe importiert hat, in der jede leere Zelle als 0 in der Zieltabelle landete, kennt die Falle: TRY_CONVERT(float, “) liefert nicht NULL, sondern 0. Der Mittelwert über die Spalte ist danach falsch, und dem Ergebnis sieht man das nicht an. Auf einen Blick: Voraussetzung: TRY_CONVERT existiert seit SQL Server 2012. Das sichere Pattern weiter unten nutzt TRIM und braucht daher SQL Server … Weiterlesen

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. Auf einen Blick: Voraussetzung: TRY_CONVERT gibt es seit SQL Server 2012. Das sichere Pattern verwendet zusätzlich TRIM und braucht damit SQL … Weiterlesen

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 Vorkommastelle zu viel. Auf einen Blick: Voraussetzung: TRY_CONVERT existiert seit SQL Server 2012. Das sichere Pattern nutzt TRIM und braucht daher SQL … Weiterlesen

Ein CSV-Import läuft ohne Fehlermeldung durch, und hinterher steht in der Mengen-Spalte eine 0, wo das Quellfeld schlicht leer war: TRY_CONVERT(int, N“) liefert 0, nicht NULL. Die zweite Eigenheit betrifft bereits typisierte Dezimalzahlen: TRY_CONVERT(int, 1234.5) rundet nicht, sondern schneidet ab — das Ergebnis ist 1234, nicht 1235. Auf einen Blick: Voraussetzung: TRY_CONVERT gibt es seit SQL Server 2012. Das sichere Pattern verwendet zusätzlich TRIM und braucht damit SQL … Weiterlesen