Réponse détaillée mais je ne suis pas d'accord quant à savoir si "SSIS ne peut pas reconnaître le format de date fourni dans la question."
Peut-être s'il était reformulé comme "SSIS ne peut pas reconnaître le format de date fourni sans aide." Le problème fondamental dans ce cas est que, par défaut, les routines d'analyse de date et de nombre sont conscient des paramètres régionaux . En général, c'est une bonne chose, sauf quand ce n'est pas le cas. Je suis tombé dessus pour la première fois lorsque j'avais affaire à des dates au format ccyammjj provenant d'un ordinateur central. Comme d'autres l'ont indiqué, il analysera dans tsql, pourquoi pas SSIS? Il existe de nombreux articles préconisant de découper et de découper les données de la chaîne pour en faire une date/heure valide, mais pourquoi passer par tous ces tracas ?
Étant donné cela comme exemple de données d'entrée (délimité par des tabulations).
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
Et un paquet qui ressemble à ça,
En modifiant un paramètre sur la Source de fichier plat , je peux faire échouer le paquet ou non.
Faites un clic droit sur la source du fichier plat et sélectionnez "Afficher l'éditeur avancé". Dans l'onglet "Propriétés d'entrée et de sortie", développez les colonnes de sortie et recherchez la colonne contenant la date. Changer le FastParse réglage de False à True .
Lorsque je l'ai exécuté, le package a initialement échoué car il perdait en précision en stockant cette valeur dans un DB_TIMESTAMP . J'ai réussi lorsque j'ai défini la colonne sur le type DB_TIMESTAMP2
Package de démonstration disponible sur https://sites .google.com/site/billfellows/home/files/FastParse.dtsx?attredirects=0&d=1
