DT_DBDATE oder DT_DBTIME statt DATETIME

[Isolde]

Hallo,
seit Kurzem versuche ich mich am MSSQL-Server 2012 und erwartungsgemäß funktioniert natürlich der Einstieg etwas holprig.
Zum Anfang versuche ich Daten aus anderen Quellen möglichst komfortabel in eine SQL-Datenbank zu übertragen.
Als Quelle verwende ich Textdateien, die Tabulator getrennte und von Anführungszeichen begrenzte Felder enthalten. Ursprünglich verwendete ich für ein Datum die folgende Form : "15.02.1980" Diese wurde aber beim Import mittels Assistenten nicht akzeptiert. Nach der Änderung in die Form "1980-02-15" wurden die Werte übernommen. Leider habe ich nicht finden können, wie ich den Server dazu bewegen kann, die erste Form zu akzeptieren.

Das nächste Problem stellte der Datentyp dar, der anschließend in der Tabelle angelegt war. Im Import-Assistenten hatte ich den Typ DT_DBDATE ausgewählt, erhielt aber ein DATETIME-Feld. Gleiches gilt auch für Zeitfelder. Die Quelle hat die Form "00:00:00", der ausgewählte Datentyp ist DT_DBTIME, der Zieldatentyp in der Tabelle ist jedoch DATETIME. Ich dachte, ich könne das korrigieren, in dem ich das gespeicherte SSIS-Paket entsprechend ändere. Denkste, auch nachdem ich dort den Zieldatentyp in DT_DBDATE bzw. DT_DBTIME geändert hatte, erhielt ich trotzdem wieder den Datentyp DATETIME.
Ich kann diese Felder zwar im Management-Studio problemlos ändern, möchte mir aber den zusätzlichen Aufwand sparen. Meine Frage lautet daher, wie man den Server bzw. das SSIS-Paket so einstellen kann, dass der gewünschte Datentyp auch erstellt wird.
Und zu guter Letzt, für leere Datumsfelder, die in der Textdatei als "" stehen, schreibt der Server '31.12.1899' ins DatumsFeld. Wie kann man diese Eigenmächtigkeit des Servers unterbinden?

Dank und Gruß
Isolde

 

[ukulele]

Deine Probleme betreffen also eher SSIS und nicht MSSQL. SSIS habe ich mal ausprobiert als es noch DTS hieß und eigentlich als brauchbares Tool in Erinnerung allerdings ist es nicht Bestandteil von MSSQL Express so das ich es hätte brauchen können (für mein CRM) aber nie verwendet habe. Ich kann dir also nur Alternativen zu SSIS Import aufzeigen, davon gibts allerdings mehrere, z.B. BULK INSERT und OPENROWSET. Das wäre dann aber quasi zu Fuss, es gibt bestimmt auch im SSIS Möglichkeiten.

DT_DBDATE und DT_DBTIME sind eher Begriffe des SSIS, MSSQL verwendet zum Speichern in der Regel immer DATETIME. Seit SQL 2008 gibt es allerdings auch DATE und TIME, die solltest du auch verwenden können. http://msdn.microsoft.com/de-de/library/ms186724.aspx Möglich das SSIS hier einfach DATETIME als kompatibelstes Format verwendet.

Auch in SSIS kann man offenbar mit Tricks arbeiten um das Datum richtig zu erkennen (cast() und substring() z.B. wie hiervorgeschlagen: https://connect.microsoft.com/SQLServer/feedback/details/286693/ssis-dt-dbdate-date-conversions ) Wichtig ist zu wissen das ein MSSQL Server ein String zu Datum unterschiedlich konvertieren kann, je nach Landes / und Spracheinstellungen. Die Amis verwenden hier YYYY-DD-MM, wir Deutschen eigentlich YYYY-MM-DD. Das kann dazu führen das er zwar YYYY-MM-DD ausgibt, aber als Input nicht mehr akzeptiert.

Der 31.12.1899 liegt eigentlich nicht im "positiven" DATETIME Bereich, entspricht SELECT cast(-1 AS DATETIME), bist du sicher das es sich hier nicht um ein Anzeigeproblem handelt? Eventuell muss man SSIS sagen wie er mit leeren Feldern zu verfahren hat um einen NULL Wert zu erhalten.

 

[Isolde]

Deine Probleme betreffen also eher SSIS und nicht MSSQL. SSIS habe ich mal ausprobiert als es noch DTS hieß und eigentlich als brauchbares Tool in Erinnerung
allerdings ist es nicht Bestandteil von MSSQL Express so das ich es hätte brauchen können (für mein CRM) aber nie verwendet habe. Ich kann dir also nur Alternativen zu SSIS Import aufzeigen, davon gibts
allerdings mehrere, z.B. BULK INSERT und OPENROWSET. Das wäre dann aber quasi zu Fuss, es gibt bestimmt auch im SSIS Möglichkeiten.

Hallo Ukulele,
vielen Dank für die schnelle Antwort.
Zu Fuß hört sich jetzt nicht so spannend an... ;-) Ursprünglich hatte ich auch die Expressversion benutzt. Da man dort aber keine SSIS-Pakete speichern kann, habe ich die Eva-Version in einer VM installiert. Mit Hilfe dieser Pakete kann man den Import ja ordentlich automatisieren, da man die mittels EXEC xp_cmdshell 'dtexec /file "C:\Daten\ImportDateien TXT???.dtsx"' gleich im Stapel abarbeiten lassen kann. Das funktioniert auch ganz gut, müssten nur noch die richtigen Feldtypen bei rumkommen.

DT_DBDATE und DT_DBTIME sind eher Begriffe des SSIS, MSSQL verwendet zum Speichern in der Regel immer DATETIME. Seit SQL 2008 gibt es allerdings auch DATE und TIME, die solltest du auch verwenden
können. http://msdn.microsoft.com/de-de/library/ms186724.aspx Möglich das SSIS hier einfach DATETIME als kompatibelstes Format verwendet.

Wegen der DATE- und TIME-Felder habe ich auch eine 2008er Datenbank angelegt. Doof nur, wenn der Importassistent das mit den neuen Feldtypen noch nicht weiß.

Auch in SSIS kann man offenbar mit Tricks arbeiten um das Datum richtig zu erkennen (cast() und substring() z.B. wie hiervorgeschlagen:
https://connect.microsoft.com/SQLServer/feedback/details/286693/ssis-dt-dbdate-date-conversions ) Wichtig ist zu wissen das ein MSSQL Server ein String zu Datum unterschiedlich konvertieren kann, je
nach Landes / und Spracheinstellungen. Die Amis verwenden hier YYYY-DD-MM, wir Deutschen eigentlich YYYY-MM-DD. Das kann dazu führen das er zwar YYYY-MM-DD ausgibt, aber als Input nicht mehr
akzeptiert.

Wie ich schon schrieb, hatte ich erst das Datumsformat "dd.mm.jjjj" verwendet. Der Importassistent bietet die Möglichkeit die Datentypen der einzelnen Felder an Hand einer auswählbaren Anzahl von Datenzeilen (max. 1Mio.) vorschlagen zu lassen. Für das angegebene Format schlägt er dann unsinniger Weise den Gleitkommatyp DT_R4 vor. Liefere ich ihm "jjjj-mm-dd" schlägt er DT_DATE vor. Diesen Typ hatte ich erst so übernommen und als dabei ein DATETIME-Feld rumkam auf DT_DBDATE geändert. Leider auch hier nicht das erwartete Ergebnis. Ich habe das Importpaket noch mal mittel Visual-Studio geöffnet und im Konvertierungs-Task nachgeschaut. Ich sehe nicht, wo ich da eine CAST-Anweisung einfügen kann.

Der 31.12.1899 liegt eigentlich nicht im "positiven" DATETIME Bereich, entspricht SELECT cast(-1 AS DATETIME), bist du sicher das es sich hier nicht um ein Anzeigeproblem handelt? Eventuell muss
man SSIS sagen wie er mit leeren Feldern zu verfahren hat um einen NULL Wert zu erhalten.

Nein, es handelt sich hier nicht um ein Anzeigeproblem. Dieses Datum wird tatsächlich so eingetragen. Man kann dem Assistenten aber in der Tat mitteilen : NULL-Werte aus der Quelle als NULL-Werte im Datenfluss beibehalten und dann unterbleibt das. Hatte ich bisher übersehen. Damit hätte sich dieses Problem erledigt.

Danke und Gruß
Isolde

 

[ukulele]

Gut, ich denke es ist nicht so tragisch DATETIME statt DATE zu verwenden. Ich weiß jetzt nicht um welche Dimensionen es hier geht Kann mir eigentlich nicht vorstellen das SSIS zwar für sich zwischen DT_DBDATE und DT_DBTIME unterscheidet aber das nicht mit DATE und TIME umsetzt. Gibt es vieleicht in den Einstellungen eine art Kompatibilitätsmodus der noch aktiv ist?

Wenn du SSIS hast würde ich ihn auch verwenden