SSRS d'Erreur: “Un ou plusieurs paramètres nécessaires à l'exécution du rapport n'ont pas été spécifiés. (rsParametersNotSpecified)”

D'accord il y a des questions similaires à cela, mais ce n'est PAS un doublon. Cette erreur apparaît lorsque vous avez des paramètres de référencement d'un jeu de données qui est partagé. La suppression du rapport à partir du serveur et le redéploiement de ne pas fixer dans mon cas.

Donc je suis en train d'élaborer sur VS 2010 Professional avec Business Intelligence Development Studio, offre, qui est sous contrôle de code source avec Team Foundation Server. Je suis pour le déploiement sur un serveur 2008R2 j'ai pensé que peut être le problème. La solution est de modifier le jeu de données de références pour être incorporé à la place qui s'arrête à cette erreur morts dans ses pistes, mais c'est assez pauvre, à mon avis, et je voudrais avoir ce travail avec les datasets partagés en fin de compte.

Choses que j'ai essayé:

Assurer la dénomination de la base de données correspond à la référence. Par exemple: "le Nom est ClientQuery, de dataset partagé est ClientQuery"
Assurer la dénomination sur le serveur correspond à la refernces à l'étape 1.
S'assurer que c'est ce qui est de la briser en supprimant la référence du dataset partagé, fonctionne tout de suite alors.
Assure que le dataset partagé est de ne pas permettre à un certain type de mise en cache sur le serveur.
J'avais un filtre sur une deuxième dataset partagé limiter le champ d'application, je l'ai enlevé et il y a toujours une erreur.
Supprimé tous les paramètres et seulement ajouté un seul dataset partagé, il donne une erreur tout de suite.
Ajout d'une option pour les paramètres de liaison à-dire: "Permettre à des valeurs Vides". Fait avec des valeurs Null.
Recréé TOUT, une toute nouvelle marque de fichier RDL, et copier-collé seuls éléments sur le corps du rapport, mais explicitement créé les paramètres et les ensembles de données et ce ENCORE ARRIVÉ.

9. Mise à JOUR - j'ai fait la vieille détruire la RDL, puis l'espoir de le redéployer. J'ai trouvé que beaucoup en ligne. Qui ne fonctionne pas dans ce cas. C'est presque comme si cette référence dans la RDL:

    < DataSet Name="**ClientQuery**">
      < SharedDataSet>
        < SharedDataSetReference>**ClientQuery**</SharedDataSetReference>
      < /SharedDataSet>
      < Fields>
        < Field Name="CUSTOMER_ID">
          < DataField>CUSTOMER_ID</DataField>
          < rd:TypeName>System.String</rd:TypeName>
        < /Field>
        < Field Name="CUSTOMER_NAME">
          < DataField>CUSTOMER_NAME</DataField>
          < rd:TypeName>System.String</rd:TypeName>
        < /Field>
      < /Fields>
    < /DataSet>

Il semble qu'en quelque sorte, la mention de cette refernce provoque des ravages. Je voudrais examiner mon bac(environnement) sous-répertoire de mon projet. (Je déployer pour de multiples environnements et à configurer QA, UAT, PROD, etc.. en vertu de la solution de config) Chaque fois que la RDL est d'obtenir des mises à jour comme il se doit et en affichant les mises à jour que je suis en train de montrer. Je pense que 'reconstruire' est beaucoup de la question de temps en temps quand les gens voient leurs fichiers de rapport pas de mise à jour sur un serveur, dans mon cas, une reconstruction obtient habituellement mises à jour de la RDL rapport à tout simplement de frapper déployer en premier.

Pendant que tout cela se passe à la partie la plus difficile est que cela fonctionne à travers les changements à chaque fois sur des OFFRES de manière transparente. Donc l'erreur est de traiter complètement avec ce que le serveur source estime que la rdl données à représenter.

Toute aide est très appréciée, j'me suis avancé à SSRS, mais cela m'a déconcerté de ce que l'erreur est refernecing qu'il n'est pas arriver.

Peut-être que vous êtes en train de vivre ce problème?
Qui est proche et j'ai pensé que trop. Cependant, je suis ÉGALEMENT d'accord avec vous sur ce point et cela continue après une suppression du rapport, de reconstruire, de les redéployer. En fait, dans ma question, j'ai créé trois rapports, un original, d'une copie de simplement copier le rapport et de le coller sous "Rapports", et la création d'une nouvelle marque à partir de zéro. Dans tous les cas, ils seraient mettre à jour les paramètres et leurs valeurs par défaut selon le cas. Cependant, si il n'y avait aucune référence n'importe où pour le dataset partagé elle allait se briser. C'est très étrange que cela pouvait arriver de nouveaux rapports.

OriginalL'auteur djangojazz | 2013-04-16

1

Bon alors la réponse Jeroen proposé et les autres est la moitié droite. Mon problème est que mon code source est sous une ancienne SVN de Contrôle à la Source, qui a été affecté à une SSRS 2008 Server, puis nous avons migré la base de code de TSF de Contrôle de Source. Le problème semble être que le partage des ensembles de données ont été CROYANT être des identifiants différents qu'ils ne l'étaient réellement. Le simple travail autour de EN OUTRE de supprimer les fichiers, est de redéployer les datasets partagés. Dans mon cas, je suis allé dans mes paramètres du projet et les a déployés dans un emplacement différent entièrement sous le rapport de la structure pour les garder dans la même région donc: Rapports/ensembles de données au lieu de simplement les ensembles de données. Cela semble résoudre le problème dans mon cas, donc je pense que c'était juste une tempête parfaite. Dans le doute avec SSRS il suffit de supprimer tout et commencer à partir du sol en place, je suppose.

OriginalL'auteur djangojazz
1

Je sais que c'est une vieille question, mais je viens de tombé sur ce et a été en mesure de résoudre mon problème. La pensée d'une mise à jour de l'option est justifiée pour les autres personnes qui luttent avec elle. Ma question a à voir avec les réglages de paramètre sur le partage des propriétés du jeu de données. Le menu ressemble à ceci:

Spécifiquement, assurez-vous que vous cochez la case "null" valeur de l'option en cas de besoin. Cette instantanément résolu mon problème où un jeu de données ne serait pas travailler quand pointant vers un partage toutefois, l'incorporation de l'ensemble de données n'.

OriginalL'auteur Wesley Marshall

Vous devez vous connecter pour publier un commentaire.