DTS itinérant

par Shane Dovers - Mis en ligne le 16/09/2004 - Publié en Octobre 2003

7 conseils pour une portabilité de package maximale

Lorsqu'on crée un package DTS, il est très important de le doter d'un maximum de portabilité. C'est ce que m'ont appris les 5 années de programmation DTS (Data Transformation Services) effectuées depuis la première livraison de SQL Server 7.0. La portabilité est maximale quand un package peut s'exécuter correctement sur la grande majorité des serveurs...Lorsque la portabilité est présente dans la conception du package, on peut déplacer le package d'un serveur sur un autre, avec peu ou pas de modifications. Cette notion est importante parce que la plupart des développeurs créent les nouveaux packages sur des serveurs de développement, puis transportent la version testée finale sur un serveur de production. Si l'on n'effectue pas toutes les modifications liées au serveur avant de porter le package sur le serveur de production, le package DTS ne s'exécutera pas correctement. Les conseils qui suivent vous aideront à  réduire le nombre de modifications nécessaires lors du déplacement d'un package et à  réduire votre temps de mise au point.
Examinons sept manières d'obtenir un maximum de portabilité quand on programme des packages DTS. Nous nous intéresserons aux deux aspects de portabilité les plus négligés : localisation des composants et sécurité à  l'exécution. Ensuite, nous étudierons les variables globales avec la Dynamic Property Task pour valider les changements dynamiques à  l'exécution, les inconvénients liés à  l'utilisation de Send Mail Task, l'utilisation des chemins UNC (Universal Naming Convention), le stockage des, et l'accès aux, fichiers source et de destination et, finalement, l'utilisation de Disconnected Edit pour modifier les attributs du package DTS.