Connexion SSIS introuvable dans le package
Je suis un peu novice dans la programmation SSIS et je rencontre des problèmes pour déployer un package SSIS.
Ce paquet fonctionne correctement sur mon PC, fait tout ce qu'il doit faire ... mais quand je le déploie, il ne peut pas trouver les chaînes de connexion.
Voici l'erreur:
Code: 0xC001000E Source: Description: La connexion "{DA7CD38D-F6AA-4B06-8014-58BEE5684364}" est introuvable. Cette erreur est levé par la collection Connections lorsque l'élément de connexion spécifique n'est pas trouvé. End Error
Erreur: 2012-08-09 00: 21: 06.25 Code: 0xC001000E Source: package Description: La connexion "{DA7CD38D-F6AA-4B06-8014-58BEE5684364}" n'est pas trouvé. Cette erreur est renvoyée par la collection Connections lorsque le fichier L'élément de connexion spécifique est introuvable. End Error
Erreur: 2012-08-09 00: 21: 06.25 Code: 0xC001000E Source: package Description: La connexion "{DA7CD38D-F6AA-4B06-8014-58BEE5684364}" n'est pas trouvé. Cette erreur est renvoyée par la collection Connections lorsque le fichier L'élément de connexion spécifique est introuvable. End Error
Erreur: 2012-08-09 00: 21: 06.25 Code: 0xC00291EB Source: Exécutez SQL Task Execute SQL Description de la tâche: Gestionnaire de connexions "{DA7CD38D-F6AA-4B06-8014-58BEE5684364}" n'existe pas. End Error
Erreur: 2012-08-09 00: 21: 06.25 Code: 0xC0024107 Source: Exécuter SQL Description de la tâche: Des erreurs se sont produites lors de la validation de la tâche. Fin Erreur DTExec: l'exécution du package a renvoyé DTSER_FAILURE (1). Commencé: 00:21:04 Terminé: 00:21:06 Temps écoulé: 1,888 secondes. Le L'exécution du paquet a échoué. L'étape a échoué.
Il semble que votre paquet ssis pointe vers une autre connexion qui aurait pu être deleted ou renamed. Essayez d'ouvrir les composants SSIS et de pointer vers la bonne connexion figurant dans votre gestionnaire de connexions.
Cela se produit lorsque nous copions les composants du package SSIS pour créer un nouveau package ou en raison du changement de nom des connexions ou que certains composants utilisent encore l'ancienne connexion définie dans votre fichier de configuration xml (essayez de vérifier la tâche d'exécution SQL erreur de projection). Si vous utilisez XML pour la configuration, essayez de déployer le nouveau.
Je suis un peu en retard pour la fête, mais je suis tombé sur ce fil tout en rencontrant les mêmes erreurs et j'ai trouvé une résolution différente.
Lors de la création d'un package SSIS 2012, dans la fenêtre de l'Explorateur de solutions, vous verrez le dossier Gestionnaires de connexion au niveau du projet. Cela semble être l’endroit le plus logique pour créer une connexion et devrait être utilisé lors de la création d’une connexion pouvant être utilisée par n’importe quel package du projet. Il est inclus au niveau du projet et non au niveau du package.
Lors de l'exécution de mon package DTSX à l'aide de Dtexec, j'ai reçu les mêmes erreurs que celles présentées ci-dessus. En effet, la connexion n’est pas incluse dans le package (uniquement le projet). Ma solution a été d'aller dans le concepteur de paquet, puis dans la fenêtre du gestionnaire de connexions, cliquez avec le bouton droit de la souris sur la connexion au niveau du projet (indiquée avec le préfixe "(projet)") et choisissez "Convertir en connexion de paquet". Cela intégrera la connexion dans le package DTSX actuel. Cela a atténué mon problème.
Cela semble également se produire lorsque vous utilisez le nouveau concept SSIS 2012 "Gestionnaire de connexions partagées", dans lequel les gestionnaires de connexions ne sont pas définis dans votre package, mais dans le projet Visual Studio et sont simplement référencés dans le package. L'exécuter via SQL Agent ou DTEXEC génère le même message d'erreur.
Je n'ai pas encore trouvé de solution pour cela, mais j'aimerais beaucoup avoir des retours si quelqu'un en a déjà fait l'expérience.
Merci d'avoir posté ce problème.
Une solution: ouvrez le package sous forme XML via Windows Explorer, recherchez le GUID du gestionnaire de connexion introuvable. Dans mon cas, il s'agissait d'une connexion EventHandler gratuite qui était corrompue. Ce même gestionnaire de connexions était utilisé dans le flux de contrôle mais n'était en aucun cas corrompu. Il n'était donc pas évident pour l'utilisateur via l'interface utilisateur. Étant donné que le XML pointait vers un gestionnaire de connexions de gestionnaire d’événements, j’ouvrais l’onglet Gestionnaire des événements de l’interface utilisateur et il affichait immédiatement le magnifique RED X sur la source et les cibles référençant l’ID du gestionnaire de connexions endommagé. Je l'ai redirigé vers le bon gestionnaire, j'ai reconstruit le paquet et enregistré. Bon pour y aller.
La clé ouvrait le paquet au format XML et localisait le GUID dans le code pour voir où il échouait. Si je ne pouvais pas trouver de référence valide dans l'interface utilisateur, j'allais renommer la connexion XML en un autre GUID connu dans le fichier XML, puis accéder à l'interface utilisateur et la recoller à nouveau ou la supprimer. tout à fait.
Bonne chance.
Dans mon cas, j’ai découvert que le problème était un fournisseur de journaux précédemment configuré, qui pointe vers une ancienne connexion qui n’est plus utilisée. Pour résoudre le problème, cliquez sur l'onglet Explorateur de packages, puis sur Fournisseurs de journaux et supprimez le fournisseur de journaux obsolète. J'espère que ça aidera quelqu'un.
Les remarques précédentes sur la suppression ou la suppression d'une connexion sont absolument possibles. Mais vous pouvez également obtenir cette erreur lorsque vous essayez d'appeler un package qui utilise des connexions au niveau du projet (au lieu de connexions au niveau du package).
Si vous utilisez des connexions au niveau du projet et souhaitez toujours utiliser dtexec, ne craignez rien. Je ne recommanderais pas de les convertir en connexions au niveau du package (en supposant que vous les ayez créées en tant que connexions au niveau du projet pour une bonne raison).
Vous devrez déployer votre projet SSIS. Un catalogue doit être créé sur votre serveur SSIS ( https://msdn.Microsoft.com/en-us/library/gg471509.aspx ). Une fois que vous avez le catalogue, dans votre projet SSIS, sélectionnez Projet-> Déployer et suivez l'assistant. Le résultat sera un fichier * .ispac généré dans votre dossier de solution SSIS/bin/Development.
Passons maintenant à la commande money, au lieu d’invoquer votre paquet avec un simple: Dtexec.exe/f "package.dtsx"
à la place, appelez-le ainsi: dtexec.exe/project "<...>/project.ispac"/package "<...>/package.dtsx"
Le fichier ispac contient les informations de connexion au niveau du projet nécessaires à l'exécution de votre package. Vous devez donc être défini!
Le forfait fonctionne bien le vendredi, vérifiez auprès de TFS et rentrez chez vous. Ouvrez-le lundi, obtenant des erreurs partout. "La variable du gestionnaire de connexions $ project._connectionstring n'a pas été trouvée dans la collection de variables".
Je clique-édite la connexion et teste la connectivité, ne fonctionne pas; ConnMnger figure dans la liste des gestionnaires de connexion de la solution. Lorsque vous ouvrez l'objet TARGET connecté à ce gestionnaire de connexions et cliquez sur MAPPINGS, l'erreur ci-dessus apparaît. Il n'y a aucune référence aux variables du gestionnaire de connexions dans le mappage.
Il s'avère que pour corriger cela, vous devez cliquer avec le bouton droit sur le gestionnaire de connexions dans la fenêtre du gestionnaire de connexions et choisir PARAMETERIZE. Remplissez les options selon vos besoins -
PROPERTY: ConnectionString Utilisez le paramètre Exisgint: $ Project :: ConnMgrName_ConnectionString OU Create New PArameter: suivez les options
Une fois ce gestionnaire de connexion paramétré, tout fonctionne. Même si Conn Manger existait dans l'onglet Conn Manger, Conn Mgr est déjà répertorié dans l'Explorateur de solutions ET n'a fonctionné aucun problème 2 jours auparavant.
Impair. Peu importe. Microsoft étant Microsoft. SQL Server étant SQL Server. Choisissez votre poison.
J'espère que cela aidera la prochaine personne à gagner du temps.
J'ai reçu cette erreur en essayant d'ouvrir un projet SSDT 2010/SSIS 2012 sous VS avec SSDT 2013. Lorsqu'il a ouvert le projet, il a demandé à migrer tous les packages. Quand je l'ai autorisé à continuer, chaque paquet a échoué avec cette erreur et d'autres. J'ai constaté qu'en contournant la conversion et en ouvrant chaque paquet individuellement, le paquet est mis à jour à l'ouverture, puis converti correctement et exécuté avec succès.
J'ai eu le même problème dans mon cas, la cause était que la connexion n'était pas intégrée et incompatibilité d'Oracle Client.
SOLUTION:
Mon environnement: SQL SERVER 2014 64bitOracle Client 32 bit
Pour inclure/intégrer la connexion
- paquet ouvert
- clic droit sur la connexion
- sélectionnez l'option "Convertir en projet"
pour le catalogue SQL SSIS/calendrier de travail définir la configuration suivre les étapes de l'image
- Droit sur 'SQL JOB-> Step "ou" Catalogue SSIS -> Package -> Exécuter "et sélectionnez" Propriétés "
- Sélectionnez Configuration -> onglet Avancé
- Checked 32-runtime
J'ai essayé de publier des images détaillées étape par étape, mais Stack Overflow ne le permet pas pour des raisons de réputation. J'espère que je mettrai plus tard ce message à jour.
J'ai eu le même problème.
J'utilise des gestionnaires de connexions au niveau du projet et mes packages fonctionnent correctement dans SSDT, mais lorsque je les déploie et les exécute via un travail avec l'agent de serveur SQL, j'obtiens des erreurs "Connexion introuvable".
J'ai donc déployé le projet, puis le problème a été résolu. Lorsque vous utilisez des gestionnaires de connexions au niveau du projet mais déployez simplement un seul package à partir de ce projet, et que vous appelez un package via l'agent du serveur SQL, il ne pouvait pas reconnaître vos gestionnaires de connexions. gestionnaires de connexion de niveau ou vous devez d’abord déployer votre projet.
J'ai déterminé que ce problème était un gestionnaire de connexions corrompu en identifiant la connexion spécifique qui échouait. Je travaille dans SQL Server 2016 et j'ai créé le catalogue SSISDB et j'y déploie mes projets.
Voici la réponse courte. Supprimez le gestionnaire de connexions, puis recréez-le avec le même nom. Assurez-vous que les paquets utilisant cette connexion sont toujours câblés correctement et vous devriez être prêt à partir. Si vous ne savez pas comment faire cela, j'ai inclus la procédure détaillée ci-dessous.
Pour identifier la connexion corrompue, j'ai procédé comme suit. Dans SSMS, j'ai ouvert le dossier Catalogues Integration Services, puis le dossier SSISDB, puis le dossier de ma solution et ainsi de suite jusqu'à ce que j'ai trouvé la liste des packages de ce projet.
En cliquant avec le bouton droit de la souris sur le package qui a échoué, en accédant à rapports> rapports standard> toutes les exécutions, en sélectionnant la dernière exécution et en affichant le rapport "Tous les messages", j'ai pu identifier quelle connexion échouait. Dans mon cas, le gestionnaire de connexion à ma destination. J'ai simplement supprimé le gestionnaire de connexions, puis recréé un nouveau gestionnaire de connexions portant le même nom.
Par la suite, je suis allé dans mon paquet, j'ai ouvert le flux de données, constaté que certaines de mes destinations s'étaient allumées avec le X rouge. J'ai ouvert la destination, j'ai re-sélectionné le nom de connexion correct, puis la table cible et vérifié les paramètres. les cartographies étaient toujours correctes. J'avais six destinations et seulement trois avaient le X rouge, mais je les ai toutes cliquées et je me suis assuré qu'elles étaient toujours configurées correctement.
j'ai eu le même problème et niether de ce qui précède résoved. Il s'est avéré qu'il y avait une vieille tâche SQL qui était désactivée dans le coin inférieur droit de mon ssis que je devais vraiment chercher. Une fois que j'ai supprimé tout cela allait bien
La valeur de la connexion dans le travail semble être sensible à la casse.
Pour les packages développés dans Visual Studio 2015, j'ai constaté que je devais fournir une valeur pour le paramètre (ce qui serait le cas lorsque vous déployez ou exécutez sur un serveur différent) qui définit la chaîne de connexion du gestionnaire de connexions au lieu d'utiliser la valeur de conception ..__ Cela supprimera le message d'erreur. Je pense que cela pourrait être un bug.
dtexec /project c:\mypath\ETL.ispac /package mypackage.dtsx /SET \Package.Variables[$Project::myParameterName];"myValueForTheParameter"
J'ai testé cela sans ou sans paramétrer la chaîne de connexion, qui se situe au niveau du projet. Le résultat était le même: c’est-à-dire que je devais définir la valeur du paramètre même s’il n’était pas utilisé.
Je constate généralement que lorsque SSIS semble se plaindre de manière irrationnelle d'une connexion apparemment bonne, c'est parce que j'essaie de définir la connexion directement à l'aide d'une variable de package plutôt que via un gestionnaire de connexion. Exemple: aujourd'hui, j'avais une tâche de service Web dans laquelle j'avais commis l'erreur de créer directement une expression définissant sa propriété "Connexion" en termes de variable de package contenant l'URL du service Web. Notez cependant qu'une connexion n'est pas la même chose qu'un ConnectionString! Ainsi, lorsque j'ai examiné la tâche, le monde entier a eu l'impression que tout était valide, car il affichait une URL parfaitement valide en tant que "Connexion". Le problème est que la connexion ne peut pas être une chaîne; ce doit être un gestionnaire de connexion.
Une autre permutation qui pose un problème dans 2008R2 est la configuration de package. J'avais défini une propriété pour qu'elle soit enregistrée/configurée à partir d'un fichier dtsconfig, puis supprimé la connexion à laquelle elle faisait référence. La résolution était simple: modifiez la configuration, désélectionnez l'objet indésirable, puis sélectionnez la propriété appropriée pour le gestionnaire de connexions renommé . L'erreur ne s'est pas reproduite après l'enregistrement, la fermeture et la réouverture du projet. :-)
Cette solution a fonctionné pour moi:
Accédez à SQL Server Management Studio, cliquez avec le bouton droit de la souris sur l'étape en échec et sélectionnez Propriétés -> Journalisation -> Supprimer le fournisseur de journaux, puis rajoutez-le.
Dans mon cas, je pourrais résoudre ce problème plus facilement. J'ai ouvert l'archive x.dtsConfig et, pour une raison inconnue, cette archive n'était pas au format standard. Par conséquent, ssis ne pouvait pas reconnaître les configurations. Heureusement, j'avais déjà sauvegardé l'archive. Il me suffisait donc de la copier dans le dossier d'origine. Tout fonctionnait à nouveau.
Ce que j’ai fait pour résoudre ce problème était simple . Je devais renommer mon serveur SQL Server afin qu’il réponde à la balise (localhos) . Après cela, j’ai modifié toutes les connexions sur SSIS et reconstruit la solution. ... cela a fonctionné . espérons que cela vous aide
Dans mon cas, l’une des tâches du gestionnaire d’événements désignait une ancienne connexion qui avait été supprimée, mais la tâche inutilisée du gestionnaire d’événements a permis de résoudre le problème . tâche!