Catalogue SSIS - Le rapport Toutes les exécutions ne montre que #Error dans toutes les en-têtes et les liens hypertexte
J'exécute un package SSIS sur une installation récente de SQL Server 2016. Récemment, le rapport All Axecutions des catalogues d'Integrations Services SSISDB a commencé à ressembler à la capture d'écran ci-dessous. Le package exécuté 5 minutes fonctionne correctement. Aucune erreur. Je peux voir les données transférées comme prévu. Quelque chose ne va pas avec ce rapport. J'ai fait des recherches et je n'arrive pas à trouver quoi que ce soit.
Quelqu'un a une idée de ce qui ne va pas? Pourquoi affiche-t-il #Error partout?
Solution: Redémarrez SSMS.
Je peux reproduire cette erreur avec SSMS 13.0.16106.4/SQL Server 13.0.4206.0 (Bien que les rapports aient fonctionné pendant un certain temps, le problème est revenu).
Avec le même utilisateur SQL, mais en exécutant SSMS 12.0.5000.0 (à partir d'un poste de travail distant), les rapports étaient satisfaisants.
Un autre utilisateur de SSMS 14.0.17177.0 n’a jamais eu ce problème.
Le redémarrage du serveur n'a eu aucun effet.
J'ai redémarré SSMS 13.0.16106.4, ce qui a résolu le problème. Cela pourrait être un problème de mémoire SSMS.
Également publié sur: https://connect.Microsoft.com/SQLServer/feedback/details/3103853/ssis-built-in-execution-reports-are-broken-in-ssms-2016-v13-0-15800- 18
J'avais exactement le même problème et je pensais au départ que c'était dû au dernier paquetage SSMS - 17.1 sous Windows 10 -, mais d'autres utilisateurs dotés de la même configuration ne rencontraient pas les erreurs.
J'ai ensuite exécuté la configuration pour SSRS (installée mais non configurée). Cela a créé les bases de données du serveur de génération de rapports sans faire de différence. Je ne pense pas que les rapports SSIS utilisent SSRS de toute façon mais je ne suis pas sûr.
J'ai ensuite exécuté Windows Update et il a installé les derniers packages .NET 4.7.
Après un redémarrage, les rapports SSIS étaient revenus à la normale!
Donc, une combinaison de ce que j'ai fait ci-dessus avec un redémarrage a fait la différence, mais il peut également s'agir d'un redémarrage nécessaire.
C’était sur ma machine de développement et j’ai sauvegardé et restauré la SSISDB de la production vers mon environnement de développement. Cela peut avoir une incidence sur la tentative de reproduire ce problème mais je ne l’ai pas expérimenté depuis et après avoir complètement supprimé et restauré le SSISDB.
J'espère que cela pourra aider?
J'ai eu ce problème. Il se trouve que j'avais supprimé certains groupes Windows de la base de données dans laquelle je chargeais des données (qui se trouvait sur un serveur complètement différent). Quand je les ai rajoutés, les rapports fonctionnaient et ne montraient pas #error
Cela n'a absolument aucun sens, bien sûr, mais je pensais que je documenterais cela au cas où cela aiderait ou améliorerait la mémoire de quelqu'un