Comment vérifier l'existence d'un fichier avant d'exécuter des tâches

-

Scénario : 

Souvent on est amené à vérifier l'existence d'un fichier dans un répertoire avant de lancer l'exécution les tâches restantes dans un package ou pas.

Solution : 

Pour ce faire, on créée 3 variables dans le package :

  • Folder_Path: nom du répertoire dans lequel on vérifie l’existence du fichier
  • File_Path: pour le chemin absolu du ficher (concaténation du chemin du répertoire et 'MonFichier.txt')
  • File_Exist_Flg : flag qui égal à "1" si le fichier existe, sinon "0"








Glisser le composant Script Task et renseigner les variables comme ci-dessous :



Le script en C# teste si le fichier existe ou pas, et affecte la bonne valeur à la variable File_Exist_Flg:

On ajoute la contrainte de précédence, 


Si le fichier existe, on poursuit l'exécution du flux de données qui suit, sinon, on l'exécute pas.





Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Comment calculer YTD, MTD en MDX - PeriodsToDate

-
Un besoin récurrent dans les rapports de Business Intelligence est de comparer les mesures à fréquence journalière ou mensuelle (chiffre d’affaire à titre d’exemple) par rapport aux mesures cumulées jusqu’à une date donnée (jour ou mois). Pour cette raison, on utilise fréquemment les notions de YTD (Year-to-Date) et MTD (month-to-Date). Plus souvent les mesures citées précédemment sont calculées dans le cube, d’autres mesures peuvent être rajoutées par ex. QTD (Qurter-to-Date) et WTD (Week-to-Date) Donc, comment calcule-t-on ces mesures en MDX ?  Pour ce faire, il existe des fonctions, à savoir : 1. YTD (member_expression) : est une fonction qui renvoie un ensemble de membres du même parent (sibling), cette liste contient en première position le premier frère et en dernière position le membre spécifié : member_expression. Ex. La fonction utilisée toute seule : YTD([Time].[CalendarMonth].[Month Id].&[201606]) renvoie la liste suivante : J...
Lire la suite

Gestion de sécurité SSRS

-
Image
SQL Server Reporting services fonctionne avec l'autorisation basé sur le rôle, et un sous-systéme pour attribuer/octroyer/accorder aux utilisateurs/groupes l'accés aux éléments d'un serveur de rapport. chaque utilisateur interagit avec le serveur de rapports dans le contexte d'un rôle qui lui définit ses accés attribués. Reporting services inclut des rôles prédéfinis, qui sont : Content Manager (gestionnaire de contenu) : a la capacité maximale de tout gérer, créer l'arborescence des rapports et les datasources y compris l'attribution de droits à d'autres utilisateurs. Publisher (rôle de publication) a le droit de publier/ajouter des rapports au serveur en plus de la création et gestion des dossiers. Browser (lecteur) a le droit d'exécuter les rapports, voir les dossiers et s'abonner sur des rapports. Report Builder (générateur de rapports)  crée/modifie des rapports dans Report Builder. My report (Mes rapports) a le droit de gérer un espac...
Lire la suite