Подробен отговор, но искам да се различавам дали „SSIS не може да разпознае формата на датата, предоставен във въпроса.“
Може би, ако беше преформулирано като „SSIS не може да разпознае предоставения формат на датата без помощ“. Основният проблем в този случай е, че по подразбиране рутинните процедури за анализ на дата и число са съзнаване на локал . Като цяло това е нещо добро, освен когато не е така. За първи път се натъкнах на това, когато се занимавах с дати във формат ccyymmdd, идващи от мейнфрейм. Както посочиха други, той ще анализира в tsql, защо не и SSIS? Има много статии, които препоръчват нарязване и нарязване на низовите данни, за да бъдат превърнати във валидна дата и час, но защо да преминавате през цялата тази караница?
Като примерни входни данни (разделени с табулатори).
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
И пакет, който изглежда така,
Като промените една настройка на източник на плосък файл , мога да направя пакета неуспешен или не.
Щракнете с десния бутон върху източника на плосък файл и изберете „Показване на разширения редактор“. В раздела „Входни и изходни свойства“ разгънете изходните колони и намерете колоната, съдържаща датата. Променете FastParse настройка от False на True .
Когато го стартирах, пакетът първоначално се провали, тъй като губеше точност при съхраняването на тази стойност в DB_TIMESTAMP . Успях, когато настроих колоната да въвежда DB_TIMESTAMP2
Демо пакет е наличен на https://sites .google.com/site/billfellows/home/files/FastParse.dtsx?attredirects=0&d=1
