Respuesta detallada, pero lamento discrepar en cuanto a si "SSIS no puede reconocer el formato de fecha proporcionado en la pregunta".
Tal vez si se reformuló como "SSIS no puede reconocer el formato de fecha proporcionado sin ayuda". El problema principal en este caso es que, de forma predeterminada, las rutinas de análisis de fecha y número son consciente de la configuración regional . En general, esto es algo bueno, excepto cuando no lo es. Me tropecé con esto por primera vez cuando estaba tratando con fechas en un formato de ccyymmdd saliendo de un mainframe. Como otros indicaron, analizará en tsql, ¿por qué no SSIS? Hay muchos artículos que abogan por cortar y trocear los datos de la cadena para convertirlos en una fecha y hora válida, pero ¿por qué pasar por todas esas molestias?
Dado esto como datos de entrada de muestra (separados por tabuladores).
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
Y un paquete que se ve así,
Al cambiar una configuración en el Fuente de archivo plano , puedo hacer que el paquete falle o no.
Haga clic con el botón derecho en el origen del archivo plano y seleccione "Mostrar editor avanzado". En la pestaña "Propiedades de entrada y salida", expanda las Columnas de salida y busque la columna que contiene la fecha. Cambie el FastParse ajuste de Falso a Verdadero .
Cuando lo ejecuté, el paquete originalmente falló porque estaba perdiendo precisión al almacenar ese valor en un DB_TIMESTAMP . Tuve éxito cuando configuré la columna para escribir DB_TIMESTAMP2
Paquete de demostración disponible en https://sites .google.com/site/billfellows/home/files/FastParse.dtsx?attredirects=0&d=1
