2015-05-05 10 views
7

Próbuję załadować plik płaski do SQL Server za pomocą zadania SSIS Data Flow. Jeśli chodzi o plik, otrzymuję kolumnę w tym kształcie 20140311115000, Jeśli zmieni się Fast Parse: False, mogę pobrać kolumnę do importu, jeśli zmienię kolumnę na 2014-03-11 11:50:00. Nie jest to optymalne, ponieważ nie mam kontroli nad plikami upstream, które mamy, i wolałbym nie parsować każdej kolumny/wiersza/tabeli. W moim połączeniu plików mam kolumnę zdefiniowaną jako: DT_DBTIMESTAMP2. W skondensowanej formie, pojawia się następujący błąd:SSIS Dataflow CSV do SQL Server z kolumną DateTime2

[ADO NET Destination [2]] Error: System.ArgumentOutOfRangeException: 
Year, Month, and Day parameters describe an un-representable DateTime. 
at System.DateTime.DateToTicks(Int32 year, Int32 month, Int32 day)...` 

Czy istnieje sposób, aby format krótsze kolumny (20140311115000) import prawidłowo?

+1

Wiesz, co jest naprawdę niesamowite w tym, że SSIS 2008 nie zawodzi. Dostaję komunikat o błędach [jacked w samej kolumnie] (http://i.stack.imgur.com/ZKi73.png) – billinkc

+0

Jeśli możesz przekonać swoich dostawców na wyższym poziomie do zmodyfikowania wartości na '20140311T115000', a następnie ustawienie FastParse = true dla tych kolumn pozwoli na importowanie natywnie jako DT_DBTIMESTAMP2 – billinkc

+0

Dzięki za tę opcję @binkinkc; Jest trochę mniej drastyczny niż inny kształt, który wiedziałem, że Fast Parse będzie również obsługiwać: '2014-03-11 11: 50: 00' –

Odpowiedz

5

Aby rozwinąć na moje komentarze, ponieważ wydaje się być akceptowalne odpowiedź:

bym sobie z tym poradzić w SSIS z pochodnej kolumnie. Ma kilka głównych zalet: po pierwsze, używa tej samej metody analizowania, co reszta procesu importowania, więc nie musisz martwić się o parsowanie pól; po drugie, wszystko odbywa się w pamięci, więc nie zapisujesz danych dwukrotnie na dysku; po trzecie, to SSIS robi transformację, a nie silnik SQL Server, więc nie ucierpi z powodu rywalizacji o zasoby (zwłaszcza jeśli twój SSIS znajduje się na innym serwerze); cztery, Derived Columns use synchronous stream processing, który jest tak szybki, jak to tylko możliwe.

Sposób, w jaki to zrobię, to zdefiniowanie pola w pliku CSV jako łańcucha znaków (DT_STR) o długości 14. Mam tendencję do zmiany nazwy kolumny wejściowej CSV "{SourceColumn} _STR" lub "{SourceColumn} _RAW ", ponieważ musisz mieć unikalne nazwy kolumn wejściowych i wyjściowych, co pozwala mi później użyć" {SourceColumn} "dla nazwy kolumny pochodnej. To sprawia, że ​​mapowanie celu jest trochę łatwiejsze, IMO. Jeśli nie zmieniasz typu danych, możesz uniknąć zastąpienia kolumny, ale jeśli zmienisz typ danych, musisz również nadać mu nową nazwę kolumny, AFAIK.

Następnie należy utworzyć zwykłe źródło danych pliku w normalny sposób w zadaniu przepływu danych. Następnie dodaj transformację kolumny pochodnej. Edycja transformacji, dać nową kolumnę do nazwy „{SourceColumn}”, skonfigurować go dodać jako nową kolumnę i sformatować ciąg i wpisać rzucać go z wyrazem jak:

(DT_DBTIMESTAMP2, 2)(SUBSTRING(MyDateColumn,1,4) + "-" + SUBSTRING(MyDateColumn,5,2) + "-" + SUBSTRING(MyDateColumn,7,2) + " " + SUBSTRING(MyDateColumn,9,2) + ":" + SUBSTRING(MyDateColumn,11,2) + ":" + SUBSTRING(MyDateColumn,13,2)) 

I mają tendencję do używania formaty od the TechNet wiki page for SSIS expressions i od the SSIS doc for Casting po prostu dlatego, że typy danych SSIS różnią się od typów danych programu SQL Server, mimo że mapują czysto. DT_GUID na przykład wymaga nawiasów klamrowych, podczas gdy UNIQUEIDENTIFIER nie.

Wykonuje się bardzo dobrze, z mojego doświadczenia. Jedyny import, jaki mam obecnie przy użyciu tej metody, jest dość mały na dość umiarkowanym sprzęcie. Importuje tylko około 12 000 rekordów, ale każdy rekord ma około 4 KB i ma ~ 240 pól i przekształca sześć lub siedem z nich. Większość z nich przekształca ciągi w DT_GUID, dodając kreski i nawiasy klamrowe, ale jedna z nich koryguje źle skonstruowane daty podobne do tych. Cały proces obejmujący zapis danych trwa od 1 do 2 sekund.