Я унаследовал очень странную аномалию в SSRS. Новый экземпляр SSRS был создан с использованием 2019 года, и, похоже, он использует ту же базу данных ReportServer, что и предыдущий экземпляр 2016 года. Это могло быть сделано, чтобы избежать переноса тысяч отчетов и связанных с ними элементов.
Экземпляр 2016 года, похоже, все еще работает, однако учетная запись, используемая для доступа к базе данных ReportingService, больше недействительна, поэтому любые попытки получить доступ к отчету с использованием URL-адреса 2016 года заканчиваются сообщением «невозможно получить доступ к базе данных сервера отчетов».
Когда я получаю доступ к отчету в 2019 году, я могу отобразить его в менеджере отчетов.
Когда я вызываю тот же отчет, используя URL-адрес экземпляра 2019 года, через вызов службы wcf ReportService2010.Render(), я получаю ту же ошибку, как если бы я обращался к службам через экземпляр 2016 года.
Alos, я знаю, что версия 2016 года пытается отобразить вызов, сделанный в 2019 году, потому что информация журнала о попытке отрисовки и ошибка «не удается подключиться к базе данных сервера отчетов» отображаются только в журнале ошибок 2016 года.
Я перепроверил журнал IIS и увидел, что служба WCF обращается к серверу 2019 для запроса рендеринга с результатом 200 (это работает по принципу «запустил и забыл», поэтому всегда возвращается 200, если конечная точка доступна).
Похоже, что wcf на самом деле вызывает экземпляр 2019 и запрашивает отчет, однако регистрация этого запроса выполняется на экземпляре SSRS 2016.
Может ли это быть связано с неправильной настройкой базы данных сервера отчетов?
решение1
Это была ошибка пользователя. App.config для службы WCF указывал на правильный экземпляр, отсюда и правильные сообщения журнала. Web.config в проекте API, который ссылался на все службы WCF, имел две настройки приложения с одинаковым ключом. Один ключ был неверным, и он использовался для привязки конечной точки ReportExecution.
Я предполагал, что конфигурации были безупречны.