28

プロジェクトをレポートサーバーにデプロイしました。

そのサーバーのデータベースに存在するビューを参照している複数のデータセットがあります。

レポートの部分に移動しようとすると、次のメッセージが表示されます。

An error has occurred during report processing. (rsProcessingAborted)
Query execution failed for dataset 'dataset1'. (rsErrorExecutingCommand)
For more information about this error navigate to the report server on the local server machine, or enable remote errors 

誰か助けてもらえますか?

4

18 に答える 18

12

問題を特定するためにリモートエラーを有効にしました。

特定のデータセット(私のビューの1つ)の列がエラーをスローしていることを確認しました。

そこで、ツール「SQL Delta」を使用して、データベースの開発バージョンとレポートサーバーのライブバージョンを比較しました。ビューの1つに、開発サーバーに追加の列があり、それがデータベースのライブバージョンにはないことに気付きました。

SQL Deltaは、ライブデータベースのビューを更新するために実行する必要のあるスクリプトを生成しました。

このスクリプトを実行し、レポートを再実行すると、すべてが機能しました。

于 2012-06-01T10:18:19.903 に答える
9

同様のエラーメッセージが表示されました。リモートエラーを有効にせずに修正できました。

レポートビルダー3.0で、 [実行]ボタンを使用してレポートを実行すると、次のようなエラーアラートが表示されました。

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

詳細ボタンを押すと、このテキストが表示されたテキストボックスが表示されます。

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)

レポートに''という名前のデータセットがなかったため、混乱してイライラしましたDataSet1.rdl確かに、テキストエディタでファイルを開いた。しばらくすると、下のテキストボックスに読めるテキストがもっとあることに気づきました。完全なエラーメッセージは次のとおりです。

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)

''という名前の共有データセットを持っていましたCustomerDetailsDataSet。SQL Server Management Studioでクエリ(テキストモードで入力された完全なSQLクエリ)を開き、そこで実行しました。使用していた列の名前が変更された特定のテーブルを明確に示すエラーメッセージが表示されました。

その時点から、新しい列で機能するようにクエリを変更し、その変更を共有データセット' CustomerDetailsDataSet'に貼り付けてから、レポートビルダーでレポートを微調整して、共有データセットへの変更を認識するのは簡単でした。

この修正後、私のレポートはこのエラーをトリガーしなくなりました。

于 2013-01-21T11:05:49.860 に答える
5

同じ問題が発生しました。これは、テーブルの一部にセキュリティが付与されていないことに関連していました。ユーザーがレポートで使用されるデータベース/テーブル/ビュー/関数などにアクセスできることを確認します。

于 2014-06-06T13:12:06.607 に答える
4

私はこれと同じ問題に対処しました。ショートカットを使用せずに、クエリに完全なソース名がリストされていることを確認してください。Visual Studioはショートカットを認識できますが、レポートサービスアプリケーションは、データの取得元のテーブルを認識できない場合があります。お役に立てば幸いです。

于 2013-04-26T18:00:52.430 に答える
4

ここにいる他の多くの人と同じように、私も同じエラーを抱えていました。私の場合は、使用したスト​​アドプロシージャの実行権限が拒否されたためです。データソースに関連付けられているユーザーにその権限が与えられたときに解決されました。

于 2014-07-02T15:57:21.563 に答える
4

私はエラーを示す同様の問題を抱えていました

このエラーの詳細については、ローカルサーバーマシンのレポートサーバーに移動するか、リモートエラーを有効にしてください。データセット「PrintInvoice」のクエリ実行に失敗しました。

解決策:1)場合によってはデータセットにエラーがある可能性があります。データセットのプロパティに移動し、[クエリデザイナ]を選択して[実行]を選択することで、データセットが期待どおりのデータを入力しているかどうかをいつでも確認できます。期待するフィールドを正常にプルできる場合は、データセットに問題がないことを確認できます。これにより、次の解決策に進みます。

2)エラーメッセージに「データセットの実行に失敗しました」と表示されている場合でも、データソース接続が原因である可能性があります。必要なテーブルがある正しいデータソースに接続し、そのデータソースにアクセスする権限があることを確認してください。

于 2015-09-18T18:52:20.383 に答える
4

私にとっての解決策はGShenaniganから来ました:

詳細については、SSRSサーバーのログファイルを確認する必要があります。それらは次のようになります: "C:\ Program Files(x86)\ Microsoft SQL Server \ MSRS10_50.DEV \ Reporting Services \ LogFiles \"

ビューが参照されているデータベーステーブルで、ビューがあった場所と同じではないアクセス許可の問題を見つけることができました。私はビューのデータベースのアクセス許可に焦点を合わせていたので、これはエラーがどこにあったかを特定するのに役立ちました。

于 2015-11-27T17:27:19.050 に答える
3

私の状況では、データセットの新しいSSRSレポートと新しいストアドプロシージャを作成しました。実行権限のあるデータベースロールにストアドプロシージャを追加するのを忘れました。EXECUTEを使用してSQLデータベースの役割にアクセス許可を追加すると、すべて問題ありませんでした。

ユーザーが遭遇したエラーメッセージは、「クライアントのレンダリング中にエラーが発生しました。レポート処理中にエラーが発生しました(rsProcessingAborted)。データセット「DataSet1」のクエリ実行に失敗しました。(rsErrorExecutingCommand)詳細については...」

于 2015-11-05T19:46:00.743 に答える
3

この素晴らしい投稿を見つけてとても感謝しています。EXECUTE私の場合、ストアドプロシージャを実行するユーザーには権限がありませんでした。EXECUTE解決策は、ストアドプロシージャの最後に以下のコードを追加することにより、ストアドプロシージャ内のユーザーにアクセス許可を付与することでした。

GRANT EXECUTE ON dbo.StoredProcNameHere TO UsernameRunningreports
GO
于 2015-12-11T17:24:02.330 に答える
2

また、非常によく似たエラーメッセージで非常によく似た問題が発生しました。私の問題は、データベースに接続できないことでした。この例では、データベースをミラーリングしており、接続文字列でフェールオーバーパートナーが指定されていません。したがって、データベースが接続できなかった場合、データベースはミラーに移動せず、このエラーをスローしていました。データソースの接続文字列でフェールオーバーパートナーを指定すると、問題が解決しました。

于 2013-10-01T14:33:45.757 に答える
2

BIGHAP:この問題の簡単な作業。

SharePointリストを使用するときにデータソースと同じ問題が発生し、上記のブログを読んで非常に役立ちました。Visual StudioのDataSourceオブジェクト名とDataオブジェクト名、およびクエリフィールドの両方に変更を加えたところ、VisualStudioでクエリが機能しました。レポートをSharePointに展開できましたが、レポートを開こうとすると、同じエラーが発生しました。

問題は、レンダリングツールの変更がすべて同期されるように、DataSourceとDataSetの両方をSharePointに再展開する必要があることだと思いました。

DataSource、DataSet、およびレポートをsharePointに再デプロイしましたが、機能しました。ブログの1つが述べているように、Visual Studioはデータセットとデータソースに加えた変更を許可しましたが、レポートを展開するときにデータソースとデータセットを自動的に再展開するようにVisual Studioを設定していない場合(これは他の人に影響を与える可能性があるため、危険な場合があります)これらのオブジェクトを共有するレポート)このエラーが発生する可能性があります。

したがって、もちろん修正は、この場合、問題を解決するためにデータソース、データセット、およびレポートを再デプロイする必要があるということです。

于 2015-02-07T19:29:59.830 に答える
2

私も同じ問題に直面していました-この問題を修正するために以下のことを確認しました、

  • データソースのポインティングデータベース名を最近変更した場合は
    、最初に、そのレポートのすべてのストアドプロシージャが変更されたデータベースに存在することを確認してください。

  • メインレポートに複数のサブレポートがある場合は、各レポートが個別に完全に実行されていることを確認してください。

  • セキュリティパネルも確認してください。ユーザーは、そのレポートのデータベース/テーブル/ビュー/関数にアクセスできる必要があります。

場合によっては、ストアドdataset1プロシージャも確認する必要があります。でレポートを表示しようとしている場合user1と同様に、このユーザーがaccess(rights)提供された(dataset1 database)データベースを持っていない場合は、上記と同じエラーがスローされるため、ユーザーがSQLServerでアクセスできることを確認する必要がありdbreaderます。

また、そのストアドプロシージャに、次のような他のデータベース(Database2)が含まれている場合

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

次に、ユーザーはこのデータベースにもアクセスできる必要があります。

注:詳細については、このパスのログファイルを確認できます。

C:\Program Files\Microsoft SQL Server\MSRS11.SQLEXPRESS\Reporting Services
于 2015-11-23T07:03:58.680 に答える
2

同じエラーが発生しましたが、これで問題は解決しました

レポートが分析サーバーに接続されている場合は、分析サーバーのモデルのユーザー(レポートサーバーにアクセスしてレポートを表示しているユーザー)に必要な権限を付与します。これを行うには、モデルまたはキューブのロールにユーザーを追加し 、モデルを分析サーバーにデプロイします。

于 2016-07-29T06:52:12.350 に答える
2

SSRS、Report Builder 3.0、MSSQL 2008、およびOracle 11Gデータベースへのクエリを使用して、Oracleストアドプロシージャが正常に実行され、エラーのない一貫した結果が得られることがわかりました。データをSSRSに取り込もうとすると、OPのクエリにリストされているエラーが発生しました。パラメータを削除した場合にのみデータがロードおよび表示されることがわかりました(お勧めできません)。さらに調べてみると、データセットのプロパティ>パラメータで、開始日をparameterName P_Startに設定し、パラメータValueを@P_Startに設定していることがわかりました。

[@P_Start]としてパラメータ値を追加すると問題が解決し、パラメータが設定された状態でデータが適切に読み込まれます。

于 2017-01-19T17:04:02.700 に答える
2

この問題は、孤立したSQLログインが原因で発生しました。お気に入りのsp_fixusersスクリプトを実行したところ、エラーは解決しました。ログを見るための上記の提案は良いものでした...そしてそれは私の答えにつながりました。

于 2017-01-31T20:25:55.210 に答える
2

これは、ビューまたはストアドプロシージャのアクセス許可の問題である可能性があります

于 2018-08-09T06:55:27.897 に答える
0

上記の回答に加えて、SQLストアドプロシージャまたはSQL関数が欠落していることが原因である可能性があります。たとえば、これは、機能が非本番領域から本番(本番)領域に移行していないことが原因である可能性があります。

于 2019-02-04T17:33:46.633 に答える
0

Select Queryからすべてのコメントを削除すると、これが修正されました。私のデータセットはプレビューで機能していましたが、Design / Query Designerに移動してそこでクエリを実行すると、ORA-01006;bind変数が存在しませんでした。選択からすべてのコメントを削除した後、それは機能しました。

于 2021-12-14T15:25:09.660 に答える