Home Page
Articoli
Tips & Tricks
News
Forum
Archivio Forum
Blogs
Sondaggi
Rss
Video
Utenti
Chi Siamo
Contattaci
Username:
Password:
Login
Registrati ora!
Recupera Password
Home Page
Stanze Forum
SQL Server 2000/2005/2008, Express, Access, MySQL, Oracle
Problema import FileFlat tramite pacchetto SSIS
venerdì 19 ottobre 2007 - 10.40
Elenco Threads
Stanze Forum
Aggiungi ai Preferiti
Cerca nel forum
roddik1980
Profilo
| Junior Member
92
messaggi | Data Invio:
ven 19 ott 2007 - 10:40
Problema import FileFlat tramite pacchetto SSIS
Buongiorno a tutti,
sto impostando un pacchetto per importare un file flat .txt contenete circa 450.000 record (con 40 campi) in una tabella di un DB SQL Server 2005. Parliamo di una anagrafica articoli. Di seguito vi espongo i miei problemi / dubbi che devo risolvere.
1) Secondo voi vista la quantità di dati è meglio importarli tutti in un' unica tabella oppure è meglio perdere più tempo all' inizio per creare più pacchetti SSIS per spezzare i dati in più tabelle visto che ho il "codicearticolo" che è la mia chiave univoca ?
2) I campi sono separati dal ; e hanno come qualificatore di testo le " " solo i campi di tipo testo, i campi numerici hanno solo il ;
Ora, in fase d' import si genera un errore per i campi numerici vuoti e per i campi numerici impostati a zero perchè nel campo no trovo lo "0" classico bensì ",000". Come devo gestire questi casi per evitare errori di conversione ?
Questi campi numerici hanno tutti 3 o 6 decimali.
Mi dite x favore che "tipo" di campo devo scegliere nella tabella di destinazione del db e che "tipo" nella definizione del datasource fileflat di SSIS. Secondo me il problema sta lì !
Inoltre come gestisco i campi numerici vuoti ? Vorrei , ma non riesco, farmi passare lo zero quando il campo numerico è vuoto !
Grazie a tutti
Mark
alx_81
Profilo
| Guru
8.814
messaggi | Data Invio:
ven 19 ott 2007 - 10:53
>Problema import FileFlat tramite pacchetto SSIS
>
>Buongiorno a tutti,
Ciao roddik1980!
>
>sto impostando un pacchetto per importare un file flat .txt contenete
>circa 450.000 record (con 40 campi) in una tabella di un DB SQL
>Server 2005. Parliamo di una anagrafica articoli. Di seguito
>vi espongo i miei problemi / dubbi che devo risolvere.
Sei riuscito a capire l'allegato che ti ho mandato l'altra sera?
http://www.dotnethell.it/forum/messages.aspx?ThreadID=18704
>
>1) Secondo voi vista la quantità di dati è meglio importarli
>tutti in un' unica tabella oppure è meglio perdere più tempo
>all' inizio per creare più pacchetti SSIS per spezzare i dati
>in più tabelle visto che ho il "codicearticolo" che è la mia
>chiave univoca ?
Le righe non sono di certo moltissime, ma nemmeno pochissime. E' importante capire quanto è pesante la tabella in termini di colonne.
Quindi ti consiglio di postare la CREATE della tua tabella per permetterci di fare alcune considerazioni sulle strutture.
Comunque, punta sempre su un buon livello di normalizzazione
.
>
>2) I campi sono separati dal ; e hanno come qualificatore di
>testo le " " solo i campi di tipo testo, i campi numerici hanno
>solo il ;
>Ora, in fase d' import si genera un errore per i campi numerici
>vuoti e per i campi numerici impostati a zero perchè nel campo
>no trovo lo "0" classico bensì ",000". Come devo gestire questi
>casi per evitare errori di conversione ?
Il null va gestito e quindi, di partenza, ti consiglio, se possibile, di rigenerare il file di testo con un valore di default per i numerici in modo che tu sappia come considerare il caso particolare.
>Questi campi numerici hanno tutti 3 o 6 decimali.
>Mi dite x favore che "tipo" di campo devo scegliere nella tabella
>di destinazione del db e che "tipo" nella definizione del datasource
>fileflat di SSIS. Secondo me il problema sta lì !
sulla tabella metterei un decimal con 3 o 6 decimali, in base ai campi. Mentre sul SSIS Numeric, impostando precision e scale.
>Inoltre come gestisco i campi numerici vuoti ? Vorrei , ma non
>riesco, farmi passare lo zero quando il campo numerico è vuoto
>!
Come ti ripeto, è meglio che sia la query di partenza che (con una ISNULL o una COALESCE ad esempio) generi i default direttamente sul file.
>
>Grazie a tutti
di nulla!
Alx81 =)
http://blogs.dotnethell.it/suxstellino
roddik1980
Profilo
| Junior Member
92
messaggi | Data Invio:
ven 19 ott 2007 - 12:22
>Problema import FileFlat tramite pacchetto SSIS
>
>Buongiorno a tutti,
Ciao roddik1980!
>
>sto impostando un pacchetto per importare un file flat .txt contenete
>circa 450.000 record (con 40 campi) in una tabella di un DB SQL
>Server 2005. Parliamo di una anagrafica articoli. Di seguito
>vi espongo i miei problemi / dubbi che devo risolvere.
Sei riuscito a capire l'allegato che ti ho mandato l'altra sera?
http://www.dotnethell.it/forum/messages.aspx?ThreadID=18704
Si tutto molto chiaro, grazie ! Ti ho risposto, vedi
http://www.dotnethell.it/forum/messages.aspx?ThreadID=18704
>
>1) Secondo voi vista la quantità di dati è meglio importarli
>tutti in un' unica tabella oppure è meglio perdere più tempo
>all' inizio per creare più pacchetti SSIS per spezzare i dati
>in più tabelle visto che ho il "codicearticolo" che è la mia
>chiave univoca ?
Le righe non sono di certo moltissime, ma nemmeno pochissime. E' importante capire quanto è pesante la tabella in termini di colonne.
Quindi ti consiglio di postare la CREATE della tua tabella per permetterci di fare alcune considerazioni sulle strutture.
Comunque, punta sempre su un buon livello di normalizzazione .
ECCOLA:
CREATE TABLE [dbo].[Tabella1](
[Campo1] [varchar](15) COLLATE Latin1_General_CI_AS NULL,
[Campo2] [varchar](60) COLLATE Latin1_General_CI_AS NULL,
[Campo3] [varchar](2) COLLATE Latin1_General_CI_AS NULL,
[Campo4] [varchar](3) COLLATE Latin1_General_CI_AS NULL,
[Campo5] [varchar](40) COLLATE Latin1_General_CI_AS NULL,
[Campo6] [varchar](8) COLLATE Latin1_General_CI_AS NULL,
[Campo7] [varchar](40) COLLATE Latin1_General_CI_AS NULL,
[Campo8] [varchar](3) COLLATE Latin1_General_CI_AS NULL,
[Campo9] [varchar](3) COLLATE Latin1_General_CI_AS NULL,
[Campo10] [varchar](1) COLLATE Latin1_General_CI_AS NULL,
[Campo11] [varchar](4) COLLATE Latin1_General_CI_AS NULL,
[Campo12] [varchar](4) COLLATE Latin1_General_CI_AS NULL,
[Campo13] [varchar](4) COLLATE Latin1_General_CI_AS NULL,
[Campo14] [varchar](15) COLLATE Latin1_General_CI_AS NULL,
[Campo15] [varchar](40) COLLATE Latin1_General_CI_AS NULL,
[Campo16] [varchar](15) COLLATE Latin1_General_CI_AS NULL,
[Campo17] [varchar](40) COLLATE Latin1_General_CI_AS NULL,
[Campo18] [varchar](15) COLLATE Latin1_General_CI_AS NULL,
[Campo19] [varchar](40) COLLATE Latin1_General_CI_AS NULL,
[Campo20] [varchar](15) COLLATE Latin1_General_CI_AS NULL,
[Campo21] [varchar](40) COLLATE Latin1_General_CI_AS NULL,
[Campo22] [float] NULL,
[Campo23] [float] NULL,
[Campo24] [varchar](3) COLLATE Latin1_General_CI_AS NULL,
[Campo25] [varchar](1) COLLATE Latin1_General_CI_AS NULL,
[Campo26] [varchar](1) COLLATE Latin1_General_CI_AS NULL,
[Campo27] [varchar](5) COLLATE Latin1_General_CI_AS NULL,
[Campo28] [varchar](1) COLLATE Latin1_General_CI_AS NULL,
[Campo29] [float] NULL,
[Campo30] [varchar](1) COLLATE Latin1_General_CI_AS NULL,
[Campo31] [varchar](2) COLLATE Latin1_General_CI_AS NULL,
[Campo32] [varchar](2) COLLATE Latin1_General_CI_AS NULL,
[Campo33] [varchar](10) COLLATE Latin1_General_CI_AS NULL,
[Campo34] [varchar](36) COLLATE Latin1_General_CI_AS NULL,
[Campo35] [int] NULL,
[Campo36] [int] NULL,
[Campo37] [float] NULL,
[Campo38] [float] NULL,
[Campo39] [float] NULL
Ho usato varchar per i campi alfanumerici perchè mi sembra occupi meno spazio di nvarchar.
Ho usato float per i campi numerici con 3 / 6 decimali (se sono a 0 vengono passato o vuoti o ,000
Ho usato int per campi numerici che so a priori essere sempre interi
>
>2) I campi sono separati dal ; e hanno come qualificatore di
>testo le " " solo i campi di tipo testo, i campi numerici hanno
>solo il ;
>Ora, in fase d' import si genera un errore per i campi numerici
>vuoti e per i campi numerici impostati a zero perchè nel campo
>no trovo lo "0" classico bensì ",000". Come devo gestire questi
>casi per evitare errori di conversione ?
Il null va gestito e quindi, di partenza, ti consiglio, se possibile, di rigenerare il file di testo con un valore di default per i numerici in modo che tu sappia come considerare il caso particolare.
Dovrei farlo io perchè il cliente che mi passa il file non può farlo ! Dovrei creare un SSIS che manipola inizialmente il fle originale e lo trasforma come voglio io.... Non so come fare !
>Questi campi numerici hanno tutti 3 o 6 decimali.
>Mi dite x favore che "tipo" di campo devo scegliere nella tabella
>di destinazione del db e che "tipo" nella definizione del datasource
>fileflat di SSIS. Secondo me il problema sta lì !
sulla tabella metterei un decimal con 3 o 6 decimali, in base ai campi. Mentre sul SSIS Numeric, impostando precision e scale.
>Inoltre come gestisco i campi numerici vuoti ? Vorrei , ma non
>riesco, farmi passare lo zero quando il campo numerico è vuoto
>!
Come ti ripeto, è meglio che sia la query di partenza che (con una ISNULL o una COALESCE ad esempio) generi i default direttamente sul file.
>
>Grazie a tutti
di nulla!
Alx81 =)
http://blogs.dotnethell.it/suxstellino
alx_81
Profilo
| Guru
8.814
messaggi | Data Invio:
ven 19 ott 2007 - 13:27
>ECCOLA:
>
>CREATE TABLE [dbo].[Tabella1](
> [Campo1] [varchar](15) COLLATE Latin1_General_CI_AS NULL,
> [Campo2] [varchar](60) COLLATE Latin1_General_CI_AS NULL,
> [Campo3] [varchar](2) COLLATE Latin1_General_CI_AS NULL,
> [Campo4] [varchar](3) COLLATE Latin1_General_CI_AS NULL,
> [Campo5] [varchar](40) COLLATE Latin1_General_CI_AS NULL,
> [Campo6] [varchar](8) COLLATE Latin1_General_CI_AS NULL,
> [Campo7] [varchar](40) COLLATE Latin1_General_CI_AS NULL,
> [Campo8] [varchar](3) COLLATE Latin1_General_CI_AS NULL,
> [Campo9] [varchar](3) COLLATE Latin1_General_CI_AS NULL,
> [Campo10] [varchar](1) COLLATE Latin1_General_CI_AS NULL,
> [Campo11] [varchar](4) COLLATE Latin1_General_CI_AS NULL,
> [Campo12] [varchar](4) COLLATE Latin1_General_CI_AS NULL,
> [Campo13] [varchar](4) COLLATE Latin1_General_CI_AS NULL,
> [Campo14] [varchar](15) COLLATE Latin1_General_CI_AS NULL,
> [Campo15] [varchar](40) COLLATE Latin1_General_CI_AS NULL,
> [Campo16] [varchar](15) COLLATE Latin1_General_CI_AS NULL,
> [Campo17] [varchar](40) COLLATE Latin1_General_CI_AS NULL,
> [Campo18] [varchar](15) COLLATE Latin1_General_CI_AS NULL,
> [Campo19] [varchar](40) COLLATE Latin1_General_CI_AS NULL,
> [Campo20] [varchar](15) COLLATE Latin1_General_CI_AS NULL,
> [Campo21] [varchar](40) COLLATE Latin1_General_CI_AS NULL,
> [Campo22] [float] NULL,
> [Campo23] [float] NULL,
> [Campo24] [varchar](3) COLLATE Latin1_General_CI_AS NULL,
> [Campo25] [varchar](1) COLLATE Latin1_General_CI_AS NULL,
> [Campo26] [varchar](1) COLLATE Latin1_General_CI_AS NULL,
> [Campo27] [varchar](5) COLLATE Latin1_General_CI_AS NULL,
> [Campo28] [varchar](1) COLLATE Latin1_General_CI_AS NULL,
> [Campo29] [float] NULL,
> [Campo30] [varchar](1) COLLATE Latin1_General_CI_AS NULL,
> [Campo31] [varchar](2) COLLATE Latin1_General_CI_AS NULL,
> [Campo32] [varchar](2) COLLATE Latin1_General_CI_AS NULL,
> [Campo33] [varchar](10) COLLATE Latin1_General_CI_AS NULL,
> [Campo34] [varchar](36) COLLATE Latin1_General_CI_AS NULL,
> [Campo35] [int] NULL,
> [Campo36] [int] NULL,
> [Campo37] [float] NULL,
> [Campo38] [float] NULL,
> [Campo39] [float] NULL
>
>Ho usato varchar per i campi alfanumerici perchè mi sembra occupi
>meno spazio di nvarchar.
>Ho usato float per i campi numerici con 3 / 6 decimali (se sono
>a 0 vengono passato o vuoti o ,000
>Ho usato int per campi numerici che so a priori essere sempre interi
Ecco.. questa è una tabella denormalizzata e piuttosto pesante.
Innanzitutto, i nomi di tabella e di colonna non sono per nulla parlanti, quindi non mi è nemmeno possibile capire se si può normalizzare.
Varchar tiene meno di nvarchar, ma non è unicode. Se non hai caratteri particolari, può andare.
Invece ti invito a fare attenzione ai float. Essendo campi a virgola mobile non garantiscono una precisione elevata. Meglio usare decimal con cifre fisse dopo la virgola (3 o 6).
Quello che volevo cercare di capire è se esiste la possibilità di trasformare colonne varchar ridondanti in tabelle di dominio su cui poi creare relazioni, in modo da salvare nella tabella di destinazione solo i campi che sono strettamente necessari a mantenere il dato corretto. Meglio sfruttare il motore relazionale evitando tabelloni così estesi.
Ci sono alcuni casi in cui un pochino di denormalizzazione non fa male, ma riguarda il mondo dei cubi e non so se è quello che serve a te.
Fai attenzione, e nel limite del possibile, almeno per i tipi di campo, scegli il più piccolo tipo adatto a contenere il più grande valore del tuo dominio.
ciao!
Alx81 =)
http://blogs.dotnethell.it/suxstellino
roddik1980
Profilo
| Junior Member
92
messaggi | Data Invio:
ven 19 ott 2007 - 16:33
1) Ecco la nuova tabella:
CREATE TABLE [dbo].[AnagraficaTXT](
[CodArticolo] [nvarchar](15) COLLATE Latin1_General_CI_AS NULL,
[DescrArticolo] [nvarchar](60) COLLATE Latin1_General_CI_AS NULL,
[StatusMMS001] [nvarchar](2) COLLATE Latin1_General_CI_AS NULL,
[TipoArticolo] [nvarchar](3) COLLATE Latin1_General_CI_AS NULL,
[DescrTipoArticolo] [nvarchar](40) COLLATE Latin1_General_CI_AS NULL,
[GruppoArticolo] [nvarchar](8) COLLATE Latin1_General_CI_AS NULL,
[DescrGruppoArticolo] [nvarchar](40) COLLATE Latin1_General_CI_AS NULL,
[BusinessArea] [nvarchar](3) COLLATE Latin1_General_CI_AS NULL,
[UnitaMisuraBase] [nvarchar](3) COLLATE Latin1_General_CI_AS NULL,
[ContabMagazzino] [nvarchar](1) COLLATE Latin1_General_CI_AS NULL,
[ClasseRischio1] [nvarchar](4) COLLATE Latin1_General_CI_AS NULL,
[ClasseRischio2] [nvarchar](4) COLLATE Latin1_General_CI_AS NULL,
[ClasseRischio3] [nvarchar](4) COLLATE Latin1_General_CI_AS NULL,
[Gerarchia1] [nvarchar](15) COLLATE Latin1_General_CI_AS NULL,
[DescrGerarchia1] [nvarchar](40) COLLATE Latin1_General_CI_AS NULL,
[Gerarchia2] [nvarchar](15) COLLATE Latin1_General_CI_AS NULL,
[DescrGerarchia2] [nvarchar](40) COLLATE Latin1_General_CI_AS NULL,
[Gerarchia3] [nvarchar](15) COLLATE Latin1_General_CI_AS NULL,
[DescrGerarchia3] [nvarchar](40) COLLATE Latin1_General_CI_AS NULL,
[Gerarchia4] [nvarchar](15) COLLATE Latin1_General_CI_AS NULL,
[DescrGerarchia4] [nvarchar](40) COLLATE Latin1_General_CI_AS NULL,
[PesoNetto] [decimal](18, 3) NULL,
[Volume] [decimal](18, 3) NULL,
[MetodoEntrataMerce] [nvarchar](3) COLLATE Latin1_General_CI_AS NULL,
[ArticoloVendita] [nvarchar](1) COLLATE Latin1_General_CI_AS NULL,
[SparePartDef] [nvarchar](1) COLLATE Latin1_General_CI_AS NULL,
[RilevMarcatura] [nvarchar](5) COLLATE Latin1_General_CI_AS NULL,
[CodiceConfig] [nvarchar](1) COLLATE Latin1_General_CI_AS NULL,
[CostoLTNAG] [decimal](18, 6) NULL,
[MetodoApprovig] [nvarchar](1) COLLATE Latin1_General_CI_AS NULL,
[StatusMMS002_001] [nvarchar](2) COLLATE Latin1_General_CI_AS NULL,
[StatusMMS002_006] [nvarchar](2) COLLATE Latin1_General_CI_AS NULL,
[CodFornitorePrinc] [nvarchar](10) COLLATE Latin1_General_CI_AS NULL,
[NomeFornitore] [nvarchar](36) COLLATE Latin1_General_CI_AS NULL,
[QtaMinAcq] [decimal](18, 0) NULL,
[LeadTime] [decimal](18, 0) NULL,
[GiacMag001] [decimal](18, 6) NULL,
[GiacMag005] [decimal](18, 6) NULL,
[GiacMag006] [decimal](18, 6) NULL
2) Per tutti i campi numerici ho il problema dei NULL, infatti nel fle flat originale ci sono molti campi numerici NULL / VUOTI. Se non gli dico di ignorare l' errore SSIS si blocca ! Non mi sembra però la soluzione giusta ! L' errore va gestito, ma come ?????
3) Mi devo preoccupare del fatto che nel file flat il separatore decimale è la "," mentre il db sql server 2005 vuole il "." ?
Secondo me c' è qualche problema:
Ho fatto verifiche a campione, per esempio se nel file flat ho il valore 112344,6 dopo l' import nel db diventa 112344.000 !
La cosa secondo me non è bella...
Cosa ne dici ?!
Grazie
Mark
alx_81
Profilo
| Guru
8.814
messaggi | Data Invio:
dom 21 ott 2007 - 19:41
>1) Ecco la nuova tabella:
>
>CREATE TABLE [dbo].[AnagraficaTXT](
> [CodArticolo] [nvarchar](15) COLLATE Latin1_General_CI_AS NULL,
> [DescrArticolo] [nvarchar](60) COLLATE Latin1_General_CI_AS NULL,
> [StatusMMS001] [nvarchar](2) COLLATE Latin1_General_CI_AS NULL,
> [TipoArticolo] [nvarchar](3) COLLATE Latin1_General_CI_AS NULL,
> [DescrTipoArticolo] [nvarchar](40) COLLATE Latin1_General_CI_AS NULL,
> [GruppoArticolo] [nvarchar](8) COLLATE Latin1_General_CI_AS NULL,
> [DescrGruppoArticolo] [nvarchar](40) COLLATE Latin1_General_CI_AS NULL,
> [BusinessArea] [nvarchar](3) COLLATE Latin1_General_CI_AS NULL,
> [UnitaMisuraBase] [nvarchar](3) COLLATE Latin1_General_CI_AS NULL,
> [ContabMagazzino] [nvarchar](1) COLLATE Latin1_General_CI_AS NULL,
> [ClasseRischio1] [nvarchar](4) COLLATE Latin1_General_CI_AS NULL,
> [ClasseRischio2] [nvarchar](4) COLLATE Latin1_General_CI_AS NULL,
> [ClasseRischio3] [nvarchar](4) COLLATE Latin1_General_CI_AS NULL,
> [Gerarchia1] [nvarchar](15) COLLATE Latin1_General_CI_AS NULL,
> [DescrGerarchia1] [nvarchar](40) COLLATE Latin1_General_CI_AS NULL,
> [Gerarchia2] [nvarchar](15) COLLATE Latin1_General_CI_AS NULL,
> [DescrGerarchia2] [nvarchar](40) COLLATE Latin1_General_CI_AS NULL,
> [Gerarchia3] [nvarchar](15) COLLATE Latin1_General_CI_AS NULL,
> [DescrGerarchia3] [nvarchar](40) COLLATE Latin1_General_CI_AS NULL,
> [Gerarchia4] [nvarchar](15) COLLATE Latin1_General_CI_AS NULL,
> [DescrGerarchia4] [nvarchar](40) COLLATE Latin1_General_CI_AS NULL,
> [PesoNetto] [decimal](18, 3) NULL,
> [Volume] [decimal](18, 3) NULL,
> [MetodoEntrataMerce] [nvarchar](3) COLLATE Latin1_General_CI_AS NULL,
> [ArticoloVendita] [nvarchar](1) COLLATE Latin1_General_CI_AS NULL,
> [SparePartDef] [nvarchar](1) COLLATE Latin1_General_CI_AS NULL,
> [RilevMarcatura] [nvarchar](5) COLLATE Latin1_General_CI_AS NULL,
> [CodiceConfig] [nvarchar](1) COLLATE Latin1_General_CI_AS NULL,
> [CostoLTNAG] [decimal](18, 6) NULL,
> [MetodoApprovig] [nvarchar](1) COLLATE Latin1_General_CI_AS NULL,
> [StatusMMS002_001] [nvarchar](2) COLLATE Latin1_General_CI_AS NULL,
> [StatusMMS002_006] [nvarchar](2) COLLATE Latin1_General_CI_AS NULL,
> [CodFornitorePrinc] [nvarchar](10) COLLATE Latin1_General_CI_AS NULL,
> [NomeFornitore] [nvarchar](36) COLLATE Latin1_General_CI_AS NULL,
> [QtaMinAcq] [decimal](18, 0) NULL,
> [LeadTime] [decimal](18, 0) NULL,
> [GiacMag001] [decimal](18, 6) NULL,
> [GiacMag005] [decimal](18, 6) NULL,
> [GiacMag006] [decimal](18, 6) NULL
Questa tabella è completamente da normalizzare.
ad esempio:
[TipoArticolo] [nvarchar](3) COLLATE Latin1_General_CI_AS NULL,
[DescrTipoArticolo] [nvarchar](40) COLLATE Latin1_General_CI_AS NULL,
[GruppoArticolo] [nvarchar](8) COLLATE Latin1_General_CI_AS NULL,
[DescrGruppoArticolo] [nvarchar](40) COLLATE Latin1_General_CI_AS NULL,
dovrebbero diventare un solo campo id, intero che punta ad una tabella che contiene lo stesso id e la descrizione.
poi:
[Gerarchia1] [nvarchar](15) COLLATE Latin1_General_CI_AS NULL,
[DescrGerarchia1] [nvarchar](40) COLLATE Latin1_General_CI_AS NULL,
[Gerarchia2] [nvarchar](15) COLLATE Latin1_General_CI_AS NULL,
[DescrGerarchia2] [nvarchar](40) COLLATE Latin1_General_CI_AS NULL,
[Gerarchia3] [nvarchar](15) COLLATE Latin1_General_CI_AS NULL,
[DescrGerarchia3] [nvarchar](40) COLLATE Latin1_General_CI_AS NULL,
[Gerarchia4] [nvarchar](15) COLLATE Latin1_General_CI_AS NULL,
[DescrGerarchia4] [nvarchar](40) COLLATE Latin1_General_CI_AS NULL,
Anche queste dovrebbero essere un elenco di tabelle con cui è composta la gerarchia. Se sai che sono sempre 4, puoi mettere 4 tabelle, 4 livelli di parentela.
GER1
-- GER2
---- GER3
------ GER4
poi, i tipi sono realmente necessari tutti NVARCHAR?
Dove possibile preferisci il varchar.
Soprattutto quelli lunghi 1, considerali come CHAR(1).. una scringa a lunghezza variabile, non tiene mai quello che leggi dentro la parentesi.
Char invece è a lunghezza fissa, in questo caso più leggero e performante.
Infine, tutto quello che è codice e che ha una descrizione (come le gerarchie e i tpi/stati) dovrebbe essere messo in tabella. In questo modo la tabella sarà molto più leggera (possiederà solo gli id di relazione verso altre tabelle) e i dati non saranno pesanti e ridondanti. Inoltre, come tipi, preferisci degli interi per le chiavi di relazione, non delle stringhe. Ad esempio:
[TipoArticolo] [nvarchar](3) COLLATE Latin1_General_CI_AS NULL,
[DescrTipoArticolo] [nvarchar](40) COLLATE Latin1_General_CI_AS NULL,
potrebbe diventare una tabella
CREATE TABLE dbo.TipiArticolo
(
IDTipoArticolo int IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED,
Descrizione varchar(40) NOT NULL
)
e la tabella che si lega (la tua ArticoliTXT) avrebbe solo IDTipoArticolo, con il risparmio di più di 45 byte..
il che, per ogni riga, significa molto.
Meno IO, più performances, eventuali indici più leggeri e veloci..
>2) Per tutti i campi numerici ho il problema dei NULL, infatti
>nel fle flat originale ci sono molti campi numerici NULL / VUOTI.
>Se non gli dico di ignorare l' errore SSIS si blocca ! Non mi
>sembra però la soluzione giusta ! L' errore va gestito, ma come?????
nel file source tu puoi specificare con un flag (nella prima schermata) se mantenere i valori null o meno.
Se si tratta di valori blank (vuoto, non spazi) ci sono due possibilità:
- se il flag "Retain NULL values from the source...." è selezionato allora nel flusso otterrai dei NULL
- se è deselezionato ti troverai nel flusso uno 0 (zero).
Questo se il campo del file è VUOTO.
Se c'è scritto NULL, o se ci sono spazi o altri caratteri, otterrai sempre errore di conversione, poichè se non ricordo male, l'hai definito numeric.
Quindi, puoi adottare le seguenti soluzioni.
1) Se possibile, cambia la query che produce il file, mettendo un valore di default (0, -1, quel che ti serve) al posto dei null.
2) Se non puoi, non passare NULL o SPAZI, ma BLANK, VUOTO, nessun valore.
3) Se devi per forza gestire un campo che non puoi cambiare alla sorgente, mettilo in una stringa e con uno script gestisci le eccezioni (sconsigliato).
Fossi in te, agirei alla radice, riscrivendo la query che produce il file.
>
>
>3) Mi devo preoccupare del fatto che nel file flat il separatore
>decimale è la "," mentre il db sql server 2005 vuole il "." ?
>
>Secondo me c' è qualche problema:
>
>Ho fatto verifiche a campione, per esempio se nel file flat ho
>il valore 112344,6 dopo l' import nel db diventa 112344.000 !
>La cosa secondo me non è bella...
In teoria, la virgola è il separatore delle migliaia, il . quello dei decimali.
Questo non per il linguaggio italiano.
Quindi, dipende da come hai installato il motore..
se è inglese, usa il punto.
>Grazie
di nulla!
Alx81 =)
http://blogs.dotnethell.it/suxstellino
roddik1980
Profilo
| Junior Member
92
messaggi | Data Invio:
dom 21 ott 2007 - 22:21
Ciao Alex_81,
chi mi produce e mi passa il file flat (estratto da archivi AS400) mi ha comunicato la lunghezza dei campi numerici e il numero max dei decimali; mi ha inoltre detto che i dati numerici sono di tipo PACKED !
Tu per caso sai il tipo PACKED a che tipo dati corrisponde sia in SSIS che in SQL Server 2005 ?
Grazie
Mark
alx_81
Profilo
| Guru
8.814
messaggi | Data Invio:
dom 21 ott 2007 - 22:34
>Ciao Alex_81,
>
>chi mi produce e mi passa il file flat (estratto da archivi AS400)
>mi ha comunicato la lunghezza dei campi numerici e il numero
>max dei decimali; mi ha inoltre detto che i dati numerici sono
>di tipo PACKED !
sigh...
non è bellissimo come tipo dati
>
>Tu per caso sai il tipo PACKED a che tipo dati corrisponde sia
>in SSIS che in SQL Server 2005 ?
Con l'advanced editor puoi configurare colonne per leggere il dato packed..
Imposta a true la proprietà UseBinaryFormat del campo che esce dal Flat File Source..
Questa proprietà carica il dato in un DT_BYTES e non fa conversioni. Poi puoi provare con una Derived Column a castarla in numeric successivamente..
Leggi qui e poi prova come nell'immagine
http://technet.microsoft.com/en-us/library/ms139941.aspx
Prova così..
624x640
81Kb
>
>Grazie
di nulla!
Alx81 =)
http://blogs.dotnethell.it/suxstellino
roddik1980
Profilo
| Junior Member
92
messaggi | Data Invio:
lun 22 ott 2007 - 09:30
Grazie ad Alex_81 per le info; ora mi leggo il tutto !
Forse riesco a farmi rifare l' export del file.txt. I dati numerici rimarranno sicuramente di tipo "PACKED". Visto che però posso definire le specifiche di export insieme a chi lo fa quali regole è bene seguire ?
Io pensavo di farmi passare il file.txt semplicemente utilizzando il "pipe" come delimitatore di campo, questo perchè ho notato che in alcuni campi (testo, descrittivi) sono contenuti sia il ";" che la "," che le "" per non parlare degli spazi.....
Tutto questo mi fa casino quindi devo trovare un simbolo per il quale sono sicuro al 100% che non sia nei campi descrittivi !
Inizialmente ho provato col ; come delimitatore e le "" come qualificatore ma ho avuto problemi perchè su 450.000 record con 40 campi trovavo spesso il ; e/o le "" all' interno dei campi testo....
Ho pensato al "pipe (|)" come delimitatore di campo senza alcun qualificatore. Cosa ne dite ?
Se avete altre indee migliori fatemele sapere per favore !
Grazie a tutti e buona giornata.
Mark
alx_81
Profilo
| Guru
8.814
messaggi | Data Invio:
lun 22 ott 2007 - 12:58
>Grazie ad Alex_81 per le info; ora mi leggo il tutto !
>
>Forse riesco a farmi rifare l' export del file.txt. I dati numerici
>rimarranno sicuramente di tipo "PACKED". Visto che però posso
>definire le specifiche di export insieme a chi lo fa quali regole
>è bene seguire ?
non packed
quando possibile..
altrimenti puoi farti passare i campi decimali con la virgola implicita..
ad esempio, se il valore che ti serve è 12345,67 fatti passare 1234567 con le specifiche che gli ultimi due sono sempre i decimali dopo la virgola. In questo modo ti basta dividere per 100 e sei a posto
>
>Io pensavo di farmi passare il file.txt semplicemente utilizzando
>il "pipe" come delimitatore di campo, questo perchè ho notato
>che in alcuni campi (testo, descrittivi) sono contenuti sia il
>";" che la "," che le "" per non parlare degli spazi.....
>Tutto questo mi fa casino quindi devo trovare un simbolo per
>il quale sono sicuro al 100% che non sia nei campi descrittivi!
Corretto.. devi scegliere un carattere che non è mai utilizzato nel resto della riga, altrimenti ti si "rompe" tutta la struttura.
>Inizialmente ho provato col ; come delimitatore e le "" come
>qualificatore ma ho avuto problemi perchè su 450.000 record con
>40 campi trovavo spesso il ; e/o le "" all' interno dei campi
>testo....
>Ho pensato al "pipe (|)" come delimitatore di campo senza alcun
>qualificatore. Cosa ne dite ?
>Se avete altre indee migliori fatemele sapere per favore !
Infatti il pipe è valido.. anche la tilde non è male (~)
>
>Grazie a tutti e buona giornata.
di nulla!
>
>Mark
Alx81 =)
http://blogs.dotnethell.it/suxstellino
roddik1980
Profilo
| Junior Member
92
messaggi | Data Invio:
lun 22 ott 2007 - 17:23
Finalmente son riuscito a fare tutto l' import.
Ora però voglio normalizzare il db / tabelle,
1° non voglio importare tutti e 40 i campi in un unica tabella. Mi basta mettere il flag sui campi che m' interessano !
2° Ok, però io vorrei creare una istruzione SELECT, per ogni set di dati da importare nelle varie tabelle, con la quale valutare i dati, per esempio fare una "SELECT DISTINCT CodArticolo, Descrizione FROM Origine FileFlat..." in questo modo prendo i record univocamente ecc...
Sostanzialmente vorrei interporre un "componente x" (non so quale) tra l' origine dati fileflat e la destinazione oledb !
A parte l' uso del "componente script" esiste un modo automatico ???
Grazie mille.
Mark
alx_81
Profilo
| Guru
8.814
messaggi | Data Invio:
lun 22 ott 2007 - 17:34
>Finalmente son riuscito a fare tutto l' import.
Bene.
>
>Ora però voglio normalizzare il db / tabelle,
>1° non voglio importare tutti e 40 i campi in un unica tabella.
>Mi basta mettere il flag sui campi che m' interessano !
In che senso il flag?
>2° Ok, però io vorrei creare una istruzione SELECT, per ogni
>set di dati da importare nelle varie tabelle, con la quale valutare
>i dati, per esempio fare una "SELECT DISTINCT CodArticolo, Descrizione
>FROM Origine FileFlat..." in questo modo prendo i record univocamente
>ecc...
>Sostanzialmente vorrei interporre un "componente x" (non so quale)
>tra l' origine dati fileflat e la destinazione oledb !
>A parte l' uso del "componente script" esiste un modo automatico???
Non capisco cosa vuoi fare..
vuoi prendere distintamente un campo?
>
Alx81 =)
http://blogs.dotnethell.it/suxstellino
roddik1980
Profilo
| Junior Member
92
messaggi | Data Invio:
lun 22 ott 2007 - 17:45
Vorrei trattare il contenuto dell' origine fileflat come una tabella statica e farvi sopra delle query !
Potrei per esempio importare tutto il fileflat in una tabella di appoggio in sql server, poi potrei farvi sopra una query SELECT DISTINCT da ssis ed estrarre per esempio il codicearticolo univoco e esportare questa SELECT in una seconda tabella.
Questa via però mi sembra un pò macchinosa ! Vorrei non usare la tabella di appoggio !
Per esempio, se dovessi farlo da codice VB aprirei una connessione al fileflat, popolo un recordset o un datareader col contenuto del fileflat SELECT DISTINCT, leggo tutto il recordset/datareader ed inserisco i dati DISTINCT nella tabella finale.
Come si può fare in SSIS ?
Grazie, ciao
Mark
alx_81
Profilo
| Guru
8.814
messaggi | Data Invio:
lun 22 ott 2007 - 19:27
>Vorrei trattare il contenuto dell' origine fileflat come una
>tabella statica e farvi sopra delle query !
>Potrei per esempio importare tutto il fileflat in una tabella
>di appoggio in sql server, poi potrei farvi sopra una query SELECT
>DISTINCT da ssis ed estrarre per esempio il codicearticolo univoco
>e esportare questa SELECT in una seconda tabella.
>Questa via però mi sembra un pò macchinosa ! Vorrei non usare
>la tabella di appoggio !
Una volta che il file è caricato negli oggetti di SSIS puoi tranquillamente fare a meno, nel tuo caso, di tabelle di appoggio.
C'è un componente che si chiama Multicast che replica una pipeline (un flusso dati) in N (dipende quante te ne servono).
Indipendentemente da questo, puoi usare un Sort Task che ti consente di ordinare i dati eliminando i duplicati e decidendo quali colonne devono essere portate con il campo/i campi per cui ordini e per cui fai quindi la distinct.
Ad esempio, potresti usare un sort task, selezionare la colonna CodiceArticolo, segnare il flag "Remove rows with duplicate sort values" e togliere l'opzione "Passthrough" alle colonne che non ti servono poi.
In questo modo avrai la distinct di un campo, ordinato per quel campo. Per questo ti consiglio di utilizzare il multicast. Perchè con un ramo puoi pensare di fare la distinct e con gli altri di eseguire altre operazioni disponendo però di tutti i metadati (e non solo della colonna distinct).
PS: Cerca di non prolungare con troppi post. Abbiamo risolto molti problemi in questo thread, e forse sarebbe meglio che per ogni argomento tu ne aprissi altri.
Se ritieni che abbia risolto alcuni tuoi quesiti ti chiedo di accettare le risposte, in modo da chiudere il thread e da fornire aiuti anche a chi cerca su questo forum.
Grazie
Alx81 =)
http://blogs.dotnethell.it/suxstellino
Torna su
Stanze Forum
Elenco Threads
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?
Dopo esserti registrato potrai chiedere
aiuto sul nostro
Forum
oppure aiutare gli altri
Consulta le
Stanze
disponibili.
Registrati ora !