0
votes

I had an SQL Server 2012 database instance installed on server A.

I then installed SSRS 2016 only (not the the complete SQL Server 2016) on server B but pointed the SSRS instance to host its ReportServer database on the SQL Server 2012 instance installed on server A.

At this point all worked well.

I then had a requirement to upgrade SSRS 2016 to SSRS 2017. I used the Microsoft SQL Server 2017 Reporting Services stand alone installer from https://www.microsoft.com/en-us/download/details.aspx?id=55252

In SSRS 2017 configuration manager, i selected to use an existing database and pointed to ReportServer database i have in the SQL Server 2012 instance i have on Server A.

In SSRS 2017 configuration manager, i have deleted all encrypted data. I can browse to the reports web portal url, see data sources and the deployed test report files but when i try to open a report, i get the error blow.

The version of the report server database is either in a format that is not valid, or it cannot be read. The found version is '2017'. The expected version is '173'. (rsInvalidReportServerDatabase)

i have tried to run delete from ReportServer.dbo.ServerUpgradeHistory where ServerVersion = 173 but i still get the same error.

Looks like the old version value is still being stored somehwere in a config file.

Where else should i look, what else should i try?

3

3 Answers

0
votes

I resolved the issue by

1- Taking backup of ReportServer databases, then deleting them

2- stopping all report services' windows services. Made them Manual startup.

3- Opened the Reporting Services Configuration form Start Menu > SQL Server {Version}

4- Starting the service from the Configuration application

5- Recreating database from Database tab

0
votes

Solution is to upgrade SQL Server 2016 to Service Pack 2: SQLServer2016SP2-KB4052908-x64-ENU https://www.microsoft.com/en-us/download/details.aspx?id=56836

0
votes

The least intrusive solution I found was this:

USE [ReportServer]
DELETE FROM ServerUpgradeHistory WHERE ServerVersion > 173

Thanks to @Henrik H in the following post:

https://serverfault.com/a/893739