2015-05-05 14 views
7

Sto provando a caricare un file flat in SQL Server tramite l'attività Flusso di dati SSIS. Per quanto riguarda il file, sto ottenendo la colonna in questa forma 20140311115000, Se passo Fast Parse: False Posso ottenere la colonna da importare se cambio la colonna in 2014-03-11 11:50:00. Questo non è ottimale anche se non ho il controllo sui file upstream che ci vengono dati, e preferisco non analizzare ogni colonna/riga/tabella. Nella mia connessione file, ho la colonna definita come: DT_DBTIMESTAMP2. Nel formato condensato, ottengo il seguente errore:SSIS Dataflow CSV a SQL Server con colonna 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)...` 

C'è un modo per rendere il formato più breve di colonna (20140311115000) import correttamente?

+1

Sapete cosa c'è di veramente meraviglioso in questo è che SSIS 2008 non fallisce. Viene visualizzato [messaggio di errore con jack nella colonna stessa] (http://i.stack.imgur.com/ZKi73.png) – billinkc

+0

Se è possibile convincere i provider upstream a modificare il valore in modo che sia '20140311T115000', quindi impostare FastParse = true per quelle colonne consentirà di importare nativamente come DT_DBTIMESTAMP2 – billinkc

+0

Grazie per l'opzione @billinkc; È un po 'meno drastico rispetto all'altra forma che sapevo che anche Fast Parse gestirà: '2014-03-11 11: 50: 00' –

risposta

5

di espandere i miei commenti dal momento che questo sembra essere una risposta accettabile:

avrei gestire questo in SSIS con una colonna derivata. Ha alcuni vantaggi importanti: in primo luogo, utilizza lo stesso metodo di analisi del resto del processo di importazione, quindi non devi preoccuparti di analizzare i campi; secondo, è tutto fatto in memoria, quindi non stai scrivendo i tuoi dati su disco due volte; terzo, è SSIS che esegue la trasformazione e non il motore di SQL Server, quindi non risentirà del conflitto di risorse (specialmente se il tuo SSIS è su un altro server); quattro, Derived Columns use synchronous stream processing, che è quasi veloce come si arriva.

Il modo in cui farei sarebbe definire il campo nel file CSV come una stringa (DT_STR) di lunghezza 14. Tendo a rinominare la colonna di input del CSV "{SourceColumn} _STR" o "{SourceColumn} _RAW ", perché è necessario disporre di nomi di colonne di input e output univoci e questo mi consente di utilizzare" {SourceColumn} "in seguito per il nome della colonna derivata. Ciò rende la mappatura della destinazione un po 'più semplice, IMO. Se non si modifica il tipo di dati, è possibile ottenere sostituendo la colonna, ma se si modifica il tipo di dati, è necessario assegnare anche un nuovo nome di colonna, AFAIK.

Quindi, successivamente si crea l'origine dati file flat normalmente nell'attività Flusso dati. Successivamente, aggiungi una trasformazione Derivata colonna. Modificare la trasformazione, dare la nuova colonna un nome di "{SourceColumn}", configurarlo da aggiungere come una nuova colonna, e formattare la stringa e digitare il cast con un'espressione del tipo:

(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)) 

tendo a usare i formati da the TechNet wiki page for SSIS expressions e da the SSIS doc for Casting semplicemente perché i tipi di dati SSIS sono diversi dai tipi di dati di SQL Server anche se mappano in modo pulito. DT_GUID, ad esempio, richiede le parentesi graffe mentre UNIQUEIDENTIFIER non lo fa.

Questo si comporta molto bene, secondo la mia esperienza. L'unica importazione che ho attualmente usando questo metodo al momento è abbastanza piccola su hardware abbastanza moderato. Importa solo circa 12.000 record, ma ogni record è di circa 4KB e ha ~ 240 campi e ne sta trasformando sei o sette. Molti di questi stanno trasformando le stringhe in DT_GUIDs aggiungendo trattini e parentesi graffe, ma una di esse sta correggendo date malformate simili a questa. L'intero processo, inclusa la scrittura dei dati, richiede tra 1 e 2 secondi.

Problemi correlati