Voici une bonne solution pour traiter des fichiers dont le nombre de colonnes est variable.
Ce type de fichier est classique quand Excel est utilisé pour générer des CSV à traiter dans SSIS.

Solution sans script:
http://agilebi.com/cs/blogs/jwelch/archive/2007/05/16/handling-varying-columns-part-2.aspx


Solution avec script:
http://agilebi.com/cs/blogs/jwelch/archive/2007/05/08/handling-flat-files-with-varying-numbers-of-columns.aspx

Suite à une demande, l'objectif de ce post est de décrire la méthode d'alimentation des Tables AuditPkgExecution,AuditTableProcessing et AuditDimension que J'utilise dans mes projets avec SSIS:

• Description des tables

AuditPkgExecution est utiliser pour le controle des Packages donc lors de l'exection de mon Etl il y aura autant d'insertion de lignes que de packages.
AuditTableProcessing represente Les flux de données (DataFlow), dans certains cas j'ai réalisé plusieurs insertions dans cette table pour un DataFlowAuditDimension est utiliser dans le cadre ou la table Alimenté est une dimension d'un Datawarehouse

• Alimentation des Tables

Dans chaque Package je crée des conteneur de sequence Pré-Execute et Post-Execute, il est aussi important dasn les DataFlow d'utiliser le composant "Nombre de lignes" pour réaliser des comptages aux endroit stategiques :
- ExtractRowCnt (Nombre de ligne extraite de la source)
- ExtractCheckValueXxxxx (Nombre de ligne après un traitement specifique)
- InsertRowCnt (Nombres de lignes Insérés)
- UpdateRowCnt (Nombres de lignes Updatés)
- ErrorRowCnt(Nombre de lignes en Erreur)
Les variables TableInitialRowCnt et TableFinalRowCnt seront alimentés avec des requettes

AuditPkgExecution : Principalement alimentée avec des variables systemes, à noté que le Master n'a pas de ParentPkgExeckey, les autres packages prendront comme valeur de ParentPkgExeckey le PkgExecKey du master. ce point sera traité avec l'utilisation des configurations dans SSIS et les variables parent.
AuditTableProcessing : pour chaque ETL cette table sera diferente mais on y retrouvera souvant les standart: Nom de la table, Nombre de lignes inserrées,Mises à jour, Suprimmées, en Erreur... pour chaque cas metier traité ou pour la gestion de rejets.
AuditDimension : personnelement je ne l'utilise que dans le cadre ou mes dimensions sont alimentés en plusieurs phases ou sur des Flocons.

le composant Merge join demande un composant de tri ou alors des données déjà triés.
Il est possible de ne pas utiliser le composant tri avec deux methodes:

1. Le composant d'extraction OleDb procède une propriété (voir les propriétés de "OleDb source Output" dans l'éditeur avancé, onglet propriété d'entrée ou de sortie)
   Passez le paramètre IsSorted à True.
2. Il est aussi possible de forcer le flag de sortie de chaque composant de lecture (requete SQL contenant un order by) à 1

Vous le savez sans doute deja, mais chaque outil de SQL Serveur 2005 à son propre mode de deployement, je me suis donc attaché à trouver un mode pour chacun. Dans le cadre ou je souhaite laisser un livrable pret à installer par mon client ou mon service d'exploitation.
Très vite on trouvera le generateur de "deployement manifest" de SSIS ainsi que les fichier de publication de SSAS à utiliser avec l'assitant de deployement.
Pour SSRS ce point est bien plus complexe.
Les choix qui s'offre à nous :
- Deploiement via Visual Studio
- Deplacement des fichiers RDL
...
Après quelques recherche je suis tomber sur le pilotage de l'application RS.exe via un fichier RSS.
il nous faut donc plusieurs elements pour effectuer un livraison avec ce mode
1 Fichier .RSS
1 Fichier .Bat (pour lancer le tout)
x fichiers .Rdl

l'utilisation de l'option "Fast Parse" du composant "Flat File" ou Fichier plat permet de gagner en performance de lecture des fichiers:
Voir les paramètres avancés du composant "Flat File" dans l'onglet proprietes> Parametrès des input/output> passer l'option Fast Parse à True.

Test de performance Par Mladen Prajdić
http://weblogs.sqlteam.com/mladenp/archive/2006/07/17/10634.aspx
Pour aller plus loin l'auteur de ce blog à utilisé les options Tablock pour gagner en performance mais dans ce cadre nous n'utilisons plus les standards de SSIS.

Afin de permettre aux packages SSIS d'être portables sous différents environnements sans avoir à re-parametrer l'ensemble des composants (je vous rappelle qu'un environnement de production ne contient pas visual studio... :) ) il est nécessaire d'utiliser un fichier de configuration.
mon choix est le fichier de configuration XML,
1- Plus flexible, il permet aux administrateurs de paramétrer les variables des différents environnements sans pour autant connaître SSIS,SQL serveur.
2- Lors de l'installation via le "Deployement manifest" il est possible d'éditer directement les configurations
3- Les paramètres gérés par ce fichiers sont sélectionnés manuellement


Tutorial:

• http://vyaskn.tripod.com/sql_server_2005_making_ssis_packages_portable.htm
• http://social.msdn.microsoft.com/Forums/en-US/sqldocumentation/thread/4982759f-29a9-4554-b44e-72b46cd52b83
• http://www.sqlis.com/post/Easy-Package-Configuration.aspx
  

Best practices:

• Sélectionner uniquement les données variables d'un environnement à un autre, nom de serveur,
• Utiliser un fichier par source de données (dans le cas ou vous avez plusieurs packages, ils ne portent pas tous les même sources)
  

1. Utiliser le bon "Protection Level", Pourquoi utiliser vous ce mode ? J'ai vu beaucoup de développeurs ne pas regarder ce paramètre alors que sa fonction est vitale pour travailler en équipe ou pour déployer sont travail.
2. Utiliser un fichier de configuration pour L'ensemble des données variables des Packages.
   Sources,Destinations, noms des serveurs...(1 par sources afin de les reutiliser dans plusieurs Packages)
3. Utiliser les transactions pour gerer l'arret des chargements en cas d'echec sans pour autant etre obliger de recharger l'ensemble des données
4. Minimiser l'appel à des programmes externes. fichiers Bat,Cmd...
5. Minimiser l'appel à des procedures stockées.(j'ai reussit beaucoup de projets sans!)
6. Découper vos flux en arborecence de packages (1 Flux = 1 Package, 1 Dimension = 1 Package)
7. Auditer les actions de vos ETL (voir methode Kimball)
8. Pourquoi ne pas utiliser les bonnes pratiques du developpement logiciel (XP, SVN...)

Sur SQLCAT:
http://sqlcat.com/top10lists/archive/2008/10/01/top-10-sql-server-integration-services-best-practices.aspx
le blog de Matthew Roche:
http://bi-polar23.blogspot.com/2007/11/ssis-best-practices-part-2.html