Mise en oeuvre d'un test de validité avec SQL Server Integration Services

Bonsoir à tous !

Si SSIS présente de grands avantages en matière de débugging de part sa conception, il n'en demeure pas moins un outil largement perfectible sur un certain nombre de points.

Le premier d'entre eux est sans doute la faiblesse des bibliothèques de fonctions accessibles dans les tâches de conversions de données. En effet, les tests classiques permettant d'identifier la bonne typologie de la donnée importée dans un Data Flow (ISDATE, ISNUMERIC, ...) ne peuvent pas être effectués autrement qu'à l'aide d'une tâche Script Component... Une tâche souvent fastidieuse et longue à développer, en particulier si le nombre de champs à tester est particulièrement important.
Si devant cette lacune importante la solution de redévelopper un composant spécifique pour SSIS vient immédiatement à l'esprit, la réalité du déploiement sur les postes clients nous rattrape inexorablement. En effet, il est nécessaire de déployer le dit composant sur tous les serveurs impactés ce qui peut s'avérer rapidement délicat...

Je viens donc ici vous proposer une solution alternative, bien que peu satisfaisante pour les perfectionnistes dont je fais partie : l'utilisation de tables temporaires !
En effet, si SSIS ne possède pas les fonctions adéquates, le Transact-SQL peut venir à notre secours !
Il convient donc d'intégrer la source de données dans une table temporaire indépendante du format des données - par exemple des champs VARCHAR - puis d'effectuer les transformations et les vérifications d'intégrité dans le cadre d'une procédure stockée...

Si cette solution demeure peu reluisante, elle reste réellement la seule solution viable tant que SQL Server Integration Services n'offrira pas une bibliothèque de composants et de fonctions satifaisante...

A suivre...

Comment connecter SSIS à un classeur Excel 2007 via OLE DB...

Bonjour à tous !

Tout d'abord, je tiens à formuler ici un GRAND merci à Radu - bon anniversaire ;-) - pour l'astuce que je vais vous présenter ci-dessous : Comment connecter SSIS à un classeur Excel 2007 via OLE DB.

En effet, le fournisseur OLE DB Microsoft Jet ne permet pas de se connecter à Excel 2007.

En revanche, il est possible de se connecter à un classeur Excel 2007 via le fournisseur Microsoft Office 12.0 Access Database Engine OLE DB Provider.
La première étape consiste à créer la connexion OLE DB et à en spécifier le fournisseur. Puis, la source de données, qui est évidemment le fichier que vous souhaitez utiliser.
Ce qui parait surprenant, c'est qu'à ce stade, la connexion ne fonctionne pas.

Il vous faut alors prendre vos petites mimines et dans l'onglet All des propriétés de votre connexion OLE DB taper la valeur "Excel 12.0" dans les propriétés étendues...
Oh, miracle de la technologie, la connexion devient alors opérationnelle...

SSIS - Bug ou feature ?

Bonjour à tous !!!

Voici une grande question concernant le tout beau SQL Server Integration Services !
En effet, bon nombre d'utilisateurs de SSIS auront pu lire ça et là que ce dernier est prévu pour gérer les fichiers XML... Et tout le monde se précipite donc sur cette fabuleuse invention qu'est le "XML File Source"... Somme toute, logique !

J'ai pu lire également que SSIS n'utilise pas les DTD pour des raisons de sécurité, et privilégie l'utilisation des tous beaux XSD !
Jusque là, pas de problème... On peut même lire qu'en cas de nécessité, il suffit de mettre la propriété DTDProhibit à False pour voir SSIS employer une technique éprouvée... Et là, les ennuis commencent !

En présentant un XML valide disposant d'une balise DOCTYPE, je ne pensais pas me retrouver à faire autant de travail dans un outil qui pour moi devait me permettre un développement rapide...
En effet, la première constatation est que la balise DOCTYPE génère une erreur... SSIS propose d'ailleurs dans son message de modifier la valeur de la propriété DTDProhibit...
Logiquement, je recherche la propriété, et là, grande surprise ! Cette propriété n'est accessible qu'en programmation ! Ainsi donc, il ne me reste que deux possibilités pour intégrer un document XML tout ce qu'il y a de plus traditionnel :
- Parser le document en mode texte et supprimer les balises DOCTYPE avant d'intégrer le fichier,
- Programmer un chargement du document dans un XmlDocument...

Résultat, l'intégration d'un simple fichier XML devient très complexe grâce à SSIS ! Bref, un grand progrès...

Donc, bug ou feature ? La firme de Redmond a-t-elle délibérément porté une attaque aux DTD ? N'était-il pas possible de laisser cette propriété visible sur le composant "XML File Source" ?
Dans tous les cas, seuls les utilisateurs s'en trouvent lésés... A mon grand regret...