Detaillierte Antwort, aber ich bin anderer Meinung, ob "SSIS das in der Frage angegebene Datumsformat nicht erkennen kann."
Vielleicht, wenn es als "SSIS kann das angegebene Datumsformat nicht ohne Hilfe erkennen" neu formuliert wurde. Das eigentliche Problem in diesem Fall ist, dass die Parsing-Routinen für Datum und Zahl standardmäßig ortsbewusst . Im Allgemeinen ist dies eine gute Sache, außer wenn es nicht so ist. Ich bin zum ersten Mal darüber gestolpert, als ich mit Daten im Format ccyymmdd zu tun hatte, die von einem Mainframe kamen. Wie andere angedeutet haben, wird es in tsql analysiert, warum nicht SSIS? Es gibt viele Artikel da draußen, die dafür plädieren, die Zeichenfolgendaten zu schneiden und zu zerteilen, um sie in eine gültige Datumszeit zu verwandeln, aber warum all diesen Aufwand betreiben?
Gegeben sei dies als Beispieleingabedaten (tabulatorgetrennt).
LongDateDesiresFastParse Gibberish
Oct 25 2011 10:18:10:756PM Hello world
Oct 24 2010 10:18:10:756PM Hello 2010 world
Oct 23 2009 10:18:10:756PM Hello 2009 world
Oct 22 2008 10:18:10:756PM Hello 2008 world
Und ein Paket, das so aussieht,
Durch Ändern einer Einstellung in der Flat File Source , kann ich das Paket zum Scheitern bringen oder nicht.
Klicken Sie mit der rechten Maustaste auf die Flatfile-Quelle und wählen Sie „Erweiterten Editor anzeigen“. Erweitern Sie auf der Registerkarte "Eingabe- und Ausgabeeigenschaften" die Ausgabespalten und suchen Sie die Spalte mit dem Datum. Ändern Sie den FastParse von False auf True setzen .
Als ich es ausführte, schlug das Paket ursprünglich fehl, da es die Genauigkeit verlor, diesen Wert in einem DB_TIMESTAMP zu speichern . Ich war erfolgreich, als ich die Spalte auf den Typ DB_TIMESTAMP2 gesetzt habe
Demopaket verfügbar unter https://sites .google.com/site/billfellows/home/files/FastParse.dtsx?attredirects=0&d=1
