Échec de L'exécution de la requête SSRS pour l'ensemble de données

j'ai rencontré un message d'erreur similaire. J'ai pu le corriger sans permettre les erreurs à distance.

Dans le Générateur de Rapports version 3.0, quand j'ai utilisé l' Exécuter bouton pour exécuter le rapport, une alerte d'erreur est apparu, en disant:

An error has occurred during report processing. (rsProcessingAborted)
[OK] [Details...]

en Appuyant sur le bouton détails m'a donné une zone de texte où j'ai vu ce texte:

For more information about this error navigate to the report server
on the local server machine, or enable remote errors
----------------------------
Query execution failed for dataset 'DataSet1'. (rsErrorExecutingCommand)

j'étais confus et frustré parce que mon rapport n'est pas un ensemble de données appelé 'DataSet1'. J'ai même ouvert le .rdl le fichier dans un texte l'éditeur pour être sûr. Au bout d'un moment, j'ai remarqué qu'il y avait plus de texte dans la zone de texte sous ce que je pouvais lire. Le message d'erreur complet est:

For more information about this error navigate to the report server
on the local server machine, or enable remote errors
----------------------------
Query execution failed for dataset 'DataSet1'. (rsErrorExecutingCommand)

----------------------------
The execution failed for the shared data set 'CustomerDetailsDataSet'.  
(rsDataSetExecutionError)
----------------------------
An error has occurred during report processing. (rsProcessingAborted)

I avoir un ensemble de données partagées nommé'CustomerDetailsDataSet'. J'ai ouvert la requête (qui était une requête SQL complète entrée en mode texte) dans SQL Server Management Studio, et je l'ai lancée là. J'ai reçu des messages d'erreur qui pointaient clairement vers une certaine table, où une colonne que j'avais utilisée avait été renommée et changée.

à partir de ce point, il était simple de modifier ma requête pour qu'elle fonctionne avec la nouvelle colonne, puis coller cette modification dans l'ensemble de données partagées 'CustomerDetailsDataSet', puis pousser le rapport dans Report Builder à reconnaître la modification de l'ensemble de données partagées.

après cette correction, mes rapports n'ont plus déclenché cette erreur.

j'ai vécu le même problème, il était lié à la sécurité n'étant pas accordée à une partie des tables. examinez votre Utilisateur a accès aux bases de données/ tableaux/vues/fonctions utilisées par le rapport.

je viens de traiter de cette même question. Assurez-vous que votre requête affiche le nom complet de la source, sans raccourci. Visual Studio peut reconnaître les raccourcis, mais votre application de services de rapports peut ne pas être en mesure de reconnaître les tableaux de vos données devraient provenir. Espérons que cela aide.

Comme beaucoup d'autres ici, j'ai eu la même erreur. Dans mon cas, c'est parce que la permission d'Exécuter a été refusée sur une procédure stockée qu'elle a utilisée. Il a été résolu lorsque l'utilisateur associé à la source de données a reçu cette autorisation.

j'ai eu le même problème en montrant l'erreur

pour plus d'informations sur cette erreur, naviguez vers le serveur de rapports sur la machine locale du serveur, ou activer l'exécution de requête d'erreurs à distance échec de l'ensemble de données "PrintInvoice".

la Solution: 1) l'erreur peut être avec l'ensemble de données dans certains cas, vous pouvez toujours vérifier si l'ensemble de données est peupler les données exactes que vous attendez en allant aux propriétés de l'ensemble de données et en choisissant "Concepteur de requête" et essayez 'exécuter', si vous pouvez avec succès tirer les champs que vous attendez, alors vous pouvez être sûr qu'il n'y a pas de problème avec l'ensemble de données, ce qui nous amène à la solution suivante.

2) Même si le message d'erreur dit "L'exécution de la requête échouée pour l'ensemble de données", une autre chance probable est avec la connexion datasource, assurez-vous que vous avez connecté à la bonne source de données qui a les tables dont vous avez besoin et vous avez les permissions pour accéder à cette source de données.

dans ma situation, j'ai créé un nouveau rapport SSRS et une nouvelle procédure stockée pour l'ensemble de données. J'ai oublié d'ajouter la procédure stockée au rôle de la base de données qui avait la permission de l'exécuter. Une fois que j'ai ajouté les permissions au rôle de base de données SQL avec EXECUTE, tout allait bien!

Le message d'erreur rencontré par l'utilisateur a été " une erreur s'est produite lors du rendu du client. Une erreur s'est produite pendant le traitement du rapport (rsProcessingAborted). L'exécution de la requête a échoué pour l'ensemble de données "DataSet1". (rsErrorExecutingCommand) pour plus d'informations..."

La solution pour moi est venu de GShenanigan:

vous aurez besoin de consulter vos fichiers journaux sur le serveur SSRS pour plus de détails. Ils seront quelque part comme: "C:\Program fichiers (x86)\Microsoft SQL Server\MSRS10_50.DEV\Reporting Services\LogFiles\"

j'ai pu trouver un problème de permissions sur une table de base de données référencée par la vue qui n'était pas la même que celle où la vue était. J'avais été porté sur les autorisations sur le voir la base de données de sorte que cela a aidé à déterminer où l'erreur était.

j'ai aussi eu un problème très similaire avec un message d'erreur très similaire. Mon problème était que la base de données ne peut pas être connecté. Dans notre cas, nous avons des bases de données miroirs et la chaîne de connexion n'a pas spécifié le Partenaire de basculement. Donc quand la base de données ne pouvait pas se connecter, elle n'est jamais allée dans le miroir et lançait cette erreur. Une fois que j'ai spécifié le Partenaire de basculement dans la chaîne de connexion pour ma source de données, il a résolu le problème.

BIGHAP: A SIMPLE WORK AROUND FOR THIS ISSUE.

j'ai rencontré le même problème en travaillant avec des listes de SharePoint comme source de données, et j'ai lu les blogs ci-dessus qui étaient très utiles. J'avais fait des changements à la fois dans la source de données et les noms d'objet de données et les champs de requête dans Visual Studio et la requête a fonctionné dans visual Studio. J'ai pu déployer le rapport sur SharePoint, mais lorsque j'ai essayé de l'ouvrir, j'ai reçu la même erreur.

j'ai pensé que le problème était que je nécessaire pour redéployer à la fois la source de données et l'ensemble de données à SharePoint afin que les changements dans les outils de rendu soient tous synchronisés.

j'ai redéployé la source de données, L'ensemble de données et le rapport à sharePoint et ça a marché. Comme l'un des blogs l'a déclaré, Bien que visual studio ait autorisé les modifications que j'ai apportées dans l'ensemble de données et datasource, si vous n'avez pas défini visual studio pour redéployer automatiquement datasource et dataset lorsque vous déployez le rapport(ce qui peut être dangereux, car cela peut affecter d'autres rapports qui partagent ces objets) cette erreur peut se produire.

donc, bien sûr, la solution est que dans ce cas, vous devez redéployer datasource, dataset et Report pour résoudre le problème.

j'ai été confrontée au même problème - j'ai vérifié les choses ci-dessous pour résoudre ce problème,

• si vous avez récemment changé de base de données de pointage-nom dans data-source
  
  puis vérifiez d'abord que toutes les procédures de stockage pour ce rapport existent sur la base de données modifiée.

• S'il y a plusieurs sous-rapports sur le rapport principal, assurez-vous que chacun rapport exécutant individuellement parfaitement.

• vérifiez aussi le panneau de sécurité-l'utilisateur doit avoir accès aux bases de données/ tables/vues/fonctions de ce rapport.

parfois, il faut aussi vérifier dataset1 magasin de la procédure. Comme si vous essayez de montrer le rapport avec user1 et si cet utilisateur n'a pas le access(rights) de (dataset1 database) base de données, puis il va lancer la même erreur que ci-dessus doit donc vérifier à l'utilisateur d'avoir accès à de l' dbreader en SQL Serveur.

aussi, si cette procédure de stockage contient une autre base de données (base de données2)

Select * from XYZ inner join Database2..Table1 on ... where...

Ensuite, l'utilisateur doit avoir l'accès à cette base de données.

Remarque: vous pouvez vérifier les fichiers journaux sur ce chemin, pour plus de détails,

C:\Program Files\Microsoft SQL Server\MSRS11.SQLEXPRESS\Reporting Services

Très reconnaissant, j'ai trouvé ce post très. Comme pour mon cas, l'utilisateur qui exécute la procédure stockée n'a pas EXECUTE autorisations. La solution était de concéder--1--> autorisations pour l'utilisateur dans la procédure stockée par l'ajout de code ci-dessous à la fin de la procédure stockée.

GRANT EXECUTE ON dbo.StoredProcNameHere TO UsernameRunningreports
GO

j'ai eu la même erreur, mais cela a fonctionné et a résolu mon problème

si le rapport est connecté au serveur D'analyse, donnez la permission requise à l'utilisateur (qui accède au serveur de rapport pour voir les rapports) dans votre serveur d'analyse. Pour ce faire ajouter l'utilisateur dans les rôles de modèle ou de cube et déployer le modèle de votre serveur d'analyse.

utilisation de SSRS, Report Builder 3.0, MSSQL 2008 et interrogation D'une base de données Oracle 11G, J'ai trouvé que la procédure stockée par oracle fonctionnait bien, produisait des résultats cohérents sans aucune erreur. Quand j'ai essayé d'apporter les données dans les SSRS, j'ai eu l'erreur telle que listée dans la requête de L'OP. J'ai trouvé que les données sont chargées et affichées uniquement si j'ai enlevé les paramètres (pas une bonne idée). Lors d'un examen plus approfondi, j'ai constaté que sous Propriétés des ensembles de données > paramètres j'avais fixé la date de début à parameterName P_Start et valeur du paramètre à @p_start.

ajouter la valeur du paramètre comme [@P_Start] a résolu le problème, et les données se chargent bien, avec les paramètres en place.

ce problème a été causé par un Login SQL orphelin. J'ai lancé mon script sp_fixusers préféré et l'erreur a été résolue. La suggestion ci-dessus d'examiner les registres était bonne...et cela m'a conduit à ma réponse.

ceci pourrait être la question de permission pour votre vue ou procédure de stockage