Gedetailleerd antwoord, maar ik ben het er niet mee eens of "SSIS het datumformaat in de vraag niet kan herkennen."
Misschien als het werd herschreven als "SSIS kan het geleverde datumformaat niet herkennen zonder hulp." Het hoofdprobleem in dit geval is dat de parseerroutines voor datum en nummer standaard lokale bewust . Over het algemeen is dit een goede zaak, behalve als dat niet zo is. Ik struikelde hier voor het eerst over toen ik te maken had met datums in het formaat ccyymmdd die van een mainframe komen. Zoals anderen al aangaven, zal het in tsql worden geparseerd, waarom niet SSIS? Er zijn tal van artikelen die pleiten voor het snijden en in blokjes snijden van de stringgegevens om er een geldige datetime van te maken, maar waarom zou je al die moeite doen?
Gezien dit als voorbeeldinvoergegevens (door tabs gescheiden).
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
En een pakket dat er zo uitziet,
Door één instelling te wijzigen op de Flat File Source , ik kan het pakket laten mislukken of niet.
Klik met de rechtermuisknop op de platte bestandsbron en selecteer 'Geavanceerde editor weergeven'. Vouw op het tabblad "Invoer- en uitvoereigenschappen" de uitvoerkolommen uit en zoek de kolom met de datum. Wijzig de FastParse instelling van False naar True .
Toen ik het uitvoerde, mislukte het pakket oorspronkelijk omdat het de precisie verloor door die waarde op te slaan in een DB_TIMESTAMP . Ik was succesvol toen ik de kolom instelde om DB_TIMESTAMP2 . te typen
Demopakket beschikbaar op https://sites .google.com/site/billfellows/home/files/FastParse.dtsx?attredirects=0&d=1