Ошибка выполнения запроса SSRS для dataset

только что развернули мой проект на моем сервере отчетов.

У меня есть несколько наборов данных, которые ссылаются на представления, существующие в БД на этом сервере.

когда я пытаюсь войти в любую часть отчета, я получаю это сообщение:

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 

кто может помочь?

16 ответов


Я включил удаленные ошибки, чтобы определить проблему.

Я определил, что столбец в определенном наборе данных (одно из моих представлений) выдает ошибку.

поэтому, используя инструмент "SQL Delta", я сравнил версию разработки базы данных с живой версией на сервере отчетов. Я заметил, что у одного из представлений был дополнительный столбец на сервере разработки, который не был на живой версии БД.

SQL Delta сгенерировал скрипт, который мне нужно было запустить чтобы обновить представление в моей live db.

Я запустил этот скрипт, повторно запустил отчет, все сработало.


я обнаружил аналогичное сообщение об ошибке. Я смог исправить это, не включив удаленные ошибки.

в Построителе отчетов 3.0, когда я использовал Run кнопка для запуска отчета, появилось предупреждение об ошибке, говоря

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-запросом, введенным в текстовом режиме) в SQL Server Management Studio и запустил его там. Я получил сообщения об ошибках, которые явно указывали на определенную таблицу, где столбец, который я использовал, был переименован и изменен.

от в этот момент было просто изменить мой запрос, чтобы он работал с новым столбцом, а затем вставить эту модификацию в общий набор данных"CustomerDetailsDataSet', а затем подтолкните отчет в Построителе отчетов, чтобы распознать изменение общего набора данных.

после этого исправления мои отчеты больше не вызывали эту ошибку.


Я испытал ту же проблему, это было связано с безопасностью, не предоставляемой части таблиц. просмотрите, что ваш пользователь имеет доступ к базам данных/ таблицам/представлениям/функциям и т. д., используемым отчетом.


Я только что занимался этим же вопросом. Убедитесь, что в запросе указано полное имя источника без использования ярлыков. Visual Studio может распознавать ярлыки, но приложение служб reporting services может не распознавать таблицы, из которых должны поступать данные. Надеюсь, это поможет.


Как и многие другие здесь, у меня была такая же ошибка. В моем случае это было потому, что разрешение было отказано на хранимую процедуру раньше. Он был разрешен, когда пользователю, связанному с источником данных, было предоставлено это разрешение.


У меня была аналогичная проблема с сообщением об ошибке

для получения дополнительной информации об этой ошибке, перейдите к серверу отчетов на локальный сервер или включить удаленное выполнение запроса ошибок ошибка набора данных "PrintInvoice".

решение: 1) ошибка может быть с набором данных в некоторых случаях вы всегда можете проверить, заполняет ли набор данных точные данные, которые вы ожидаете, перейдя в свойства набора данных и выбрав "конструктор запросов" и попробуйте "выполнить", если вы можете успешно вытащить поля, которые вы ожидаете, то вы можете быть уверены, что нет никаких проблем с набором данных, который приведет нас к следующему решению.

2) несмотря на то, что в сообщении об ошибке говорится "выполнение запроса не удалось для набора данных", другие вероятные шансы связаны с подключением источника данных, убедитесь, что вы подключились к правильному источнику данных, который имеет необходимые таблицы, и у вас есть разрешения на доступ к этому источнику данных.


в моей ситуации, я создал новый отчет SSRS и новую хранимую процедуру для набора данных. Я забыл добавить хранимую процедуру в роль базы данных, которая имела разрешение на ее выполнение. Как только я добавил разрешения на роль базы данных SQL с EXECUTE, все было в порядке!

сообщение об ошибке, обнаруженное пользователем, было " во время отрисовки клиента произошла ошибка. Произошла ошибка при обработке отчета (rsProcessingAborted). Не удалось выполнить запрос для набора данных "Имя dataset1'. (rsErrorExecutingCommand) для получения дополнительной информации..."


решение для меня пришло из GShenanigan:

вам необходимо проверить ваш лог-файлы на сервера SSRS более подробно. Они будут где-то вроде: C:\Program файлы (x86)\Microsoft SQL Server\MSRS10_50.DEV\Reporting Services\LogFiles\"

Я смог найти проблему разрешений в таблице базы данных, на которую ссылается представление, которое не было таким же, как где было представление. Я был сосредоточен на разрешениях на база данных view, так что это помогло определить, где была ошибка.


У меня также была очень похожая проблема с очень похожим сообщением об ошибке. Моя проблема заключалась в том, что база данных не может быть подключен. В нашем случае у нас есть зеркальные базы данных, и строка подключения не указала партнера по отработке отказа. Поэтому, когда база данных не могла подключиться, она никогда не шла к зеркалу и бросала эту ошибку. Как только я указал партнера по отказоустойчивости в строке подключения для моего источника данных, он решил проблему.


BIGHAP: ПРОСТАЯ РАБОТА ВОКРУГ ЭТОЙ ПРОБЛЕМЫ.

Я столкнулся с той же проблемой при работе со списками SharePoint, что и источник данных, и прочитал блоги выше, которые были очень полезны. Я внес изменения в имена источников данных и объектов данных и поля запросов в Visual Studio, и запрос работал в visual Studio. Я смог развернуть отчет в SharePoint, но когда я попытался открыть его, я получил ту же ошибку.

Я догадался, что проблема в том, что я необходимо повторно развернуть источник данных и набор данных в SharePoint, чтобы синхронизировать все изменения в инструментах визуализации.

Я перераспределил источник данных, набор данных и отчет в sharePoint, и это сработало. Как указано в одном из блогов, хотя visual studio разрешила изменения, внесенные мной в dataset и datasource, если вы не настроили visual studio для автоматического повторного развертывания datasource и dataset при развертывании отчета(что может быть опасно, поскольку это может повлиять другие отчеты, которые совместно используют эти объекты) эта ошибка может возникнуть.

Итак, конечно, исправление заключается в том, что в этом случае вам нужно повторно развернуть источник данных, набор данных и отчет для решения проблемы.


Я также столкнулся с той же проблемой - я проверил ниже вещи, чтобы исправить эту проблему,

  • если вы недавно изменили имя указывающей базы данных в источнике данных
    затем сначала убедитесь, что все процедуры хранилища для этого отчета существуют на измененной базе данных.

  • если есть несколько суб-отчетов по основному отчету, убедитесь, что каждый отчет индивидуально работает отлично.

  • также проверьте панель безопасности - пользователь должен иметь доступ к базам данных/ таблицы / представления / функции для этого доклада.

иногда нам также нужно проверить dataset1 - хранимая процедура. Как будто вы пытаетесь показать отчет с user1 и если у этого пользователя нет access(rights) предоставленной (dataset1 database) база данных, то он будет бросать ту же ошибку, что и выше, поэтому должен проверить пользователь имеет доступ dbreader in SQL-сервер.

кроме того, если эта процедура хранения содержит некоторую другую базу данных (база данных 2) как

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

тогда пользователь также должен иметь доступ к этой базе данных.

Примечание: вы можете проверить файлы журнала на этот путь для получения более подробной информации,

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

очень благодарен, что я нашел этот отличный пост. Что касается моего случая, у пользователя, выполняющего хранимую процедуру, не было EXECUTE разрешения. Решение предоставить EXECUTE разрешения для пользователя в хранимой процедуре, добавив следующий код в конец хранимой процедуры.

GRANT EXECUTE ON dbo.StoredProcNameHere TO UsernameRunningreports
GO

Я получил ту же ошибку, но это сработало и решило мою проблему

если отчет подключен к серверу Analysis server, предоставьте необходимые разрешения пользователю (который обращается к серверу reporting server для просмотра отчетов) в вашей модели сервера analysis server. Сделать это Добавить пользователя в роли модели или Куба и разверните модель на сервере analysis server.


использование SSRS, построителя отчетов 3.0, MSSQL 2008 и запрос к базе данных Oracle 11G, Я обнаружил, что хранимая процедура oracle работает хорошо, дает последовательные результаты без ошибок. Когда я попытался принести данные в SSRS, я получил ошибку, как указано в запросе OP. Я обнаружил, что данные загружаются и отображаются только в том случае, если я удалил параметры (не очень хорошая идея). При дальнейшем рассмотрении я обнаружил, что в разделе свойства набора данных>параметры я установил дату начала в parameterName P_Start и значение параметра @P_Start.

добавление значения параметра как [@P_Start] очистило проблему, и данные загружаются хорошо, с параметрами на месте.


эта проблема была вызвана потерянным именем входа SQL. Я запустил свой любимый скрипт sp_fixusers, и ошибка была решена. Приведенное выше предложение взглянуть на журналы было хорошим...и это привело меня к ответу.


Это может быть проблема с разрешением для процедуры просмотра или хранения