2016-11-03 1 views
0

J'ai un projet SSIS sur lequel j'ai travaillé. J'ai déménagé sur un nouveau poste de travail, et lorsque j'essaie d'exécuter les packages SSIS à partir de VS 2015 sur ce nouveau poste de travail, ils terminent immédiatement leur travail. Le journal de progression reste vide, et le journal de sortie montre que deux lignes:Les packages SSIS ne s'exécutent pas lorsqu'ils sont exécutés à partir de Visual Studio

SSIS package "C:\MyFolder\MyPackage.dtsx" starting. 
SSIS package "C:\MyFolder\MyPackage.dtsx" finished: Canceled. 

je peux déployer les paquets à SQL Server, et ils courent bien. D'autres projets SSIS sur ce poste de travail s'exécutent sans problème, et l'exécution de ces paquets de problèmes à partir d'autres stations de travail fonctionne également sans problème.

Quelqu'un at-il une idée de ce qui pourrait être le problème et/ou des conseils pour résoudre ce problème?

+0

J'ai essayé de changer TargetServerVersion de SQL Server 2012 à 2016, ce qui a permis l'exécution du paquet. Cependant, les versions 2012 et 2014 donnent les mêmes résultats. Nouveaux projets dans une solution différente sous 2012 sans problème. –

Répondre

0

La solution finale a fini par être des versions incompatibles du connecteur Attunity pour Oracle.

Sur le nouveau poste de travail, j'avais seulement installé la version 4.0. Une fois que j'ai installé les versions 3.0 et 2.0, les paquets ont commencé à fonctionner sans problème. C'est même si la plupart des paquets que je testais n'utilisaient pas le connecteur Attunity. Le simple fait d'avoir un gestionnaire de connexion MSORA dans mon projet était suffisant pour que tout cela s'effondre. Moralité de l'histoire: Même si la version 4.0 doit être installée pour permettre au concepteur de VS2015 d'accéder et d'utiliser le connecteur/Sources/Destinations, vous avez toujours besoin de la version spécifique à SSIS TargetServerVersion que vous utilisez. en utilisant installé aussi bien.

1

Semble clairement comme un problème environnemental. Fonctionne en ciblant 2016, pas en ciblant 2012. Nouveau poste de travail, nouveaux problèmes.

Le numéro de version de SSDT correspond-il aux machines? Quelle est votre version actuelle? Et la version sur l'ancienne machine? Vérifiez here sur la façon de trouver les numéros de version SSDT.

Je demande parce que ce son similaire à MS Connect 755959 a été résolu avec une mise à jour de service pack.

Si vos numéros de version correspondent, alors this blog a d'excellentes informations sur le dépannage des erreurs d'annulation de paquet.

Bonne chance!

+0

Merci Troy. Les deux versions de SSDT sont les mêmes (14.0.61021.0). J'avais déjà lu ce post. Malheureusement, beaucoup de suggestions ne s'appliquaient pas parce que c'est le débogage de mon poste de travail local en SSDT, plutôt que de s'exécuter sur SSIS sur une installation SQL native. Après 2 jours d'essais, j'ai finalement réussi à le résoudre, ce que je vais écrire. –