My client has two business databases running on SQL Server 2005, together with SSRS databases (ReportServer and ReportServerTempDB), all on the same W2K3 server. My client is thinking about separate the SSRS out from the server, moving to a W2k12 R2 server, and upgrade the SSRS databases to SQL Server 2014, but with the business databases remain on SQL server 2005/W2k3 (because of $$$).
Will that be possible and is that likely to experience problems in the future?
Thanks in advance.
p.s. I should also mention there are two .NET 4.0 C# apps connected to the business and SSRS databases atm. SSRS databases are full of overnight generated report snapshots, plus ad-hoc reports generated via the apps. The SSRS db is about 80GB.
I do agree with BIDeveloper, the only way to really be sure of this is to test it. However, I can tell you from experience that so long as your report writers do not try to take advantage of new features found in the new sql server version that your SSRS instance is running off, you should be fine.
We had a similar situation where our databases were 2008r2, running on windows 2008r2 servers, but our SSRS was running on a windows 2012 server, with the SQL Server backing for SSRS was running on SQLServer 2012. - It was fine - so long as all the SSRS reports were able to run against the 2008r2 sql servers. We had a few bad report writers that tried to use sql server 2012 functions that didn't run on 2008, and those reports had errors. After the report writer fixed their mistake, the reports worked fine.
An example off the top of my head would be if a report writer wrote the following query to be executed in the report:
SELECT
TRY_CONVERT(INT, 100) [SomeConvertedInt]
FROM
<SOMETABLE>
It would work fine on their local development machine running SQL 2012, but would fail when the report was being executed on the SSRS server. To fix, they would have to remove the new 2012 function - in this case, TRY_CONVERT().
You need to create a new SSRS instance at the version you are proposing - without touching the old instance. Then do full testing.
This is the only way to prove your plan will work.
Related
I have downloaded, installed, & tried to configure evaluation copies of 2019 SQL Server & 2017 SSRS.
When I used Report Server Configuration Manager, I put my new instance of the SQL database engine (MSSQLSERVER05) into the database name.
This connected properly.
Through multiple tries, I have created multiple report servers & temp report servers.
However, when I try to access SSRS from the Object Explorer of SSMS 18.5, 2 old DB names & "SSRS" are the only instances I see.
I have tried using SSRS, but the error says the reporting service instance cannot be found.
If I type in the name of the new database engine (MSSQLSERVER05), I get the same error.
I have had earlier trials of SQL, but tried to uninstall all of them.
I notice that the file rsreportserver.config has "SSRS" in it as well as a coded database name.
This likely needs to change somehow. I would appreciate any help!
Thanks!
Ginger
First, use Developer Edition instead of Evaluation Edition for non-production scenarios, as it's not timebombed.
when I try to access SSRS from the Object Explorer of SSMS 18.5,
There's not really much use in using SSMS to connect to the Report Server. Just open the Report Manager Portal in your browser.
old DB names & "SSRS" are the only instances I see
Not sure, but SSRS 2017 is not installed as part of a SQL Server instance, and you can't have multiple instances installed on a computer. This change was part of the transition of SSRS be a scaled-down edition of Power BI Report Server.
Qualifying information: we use Crystal Reports 8.5 and our current application is written in VB6. Our original database was SQL Server 2005 and currently we run on SQL Server 2012, however are set to the 2005 compatibility level (level 90). We created a new database in SQL Server 2014 and have hooked the application up to the new server successfully, however now the Crystal Reports do not render properly (data showing up in places it should not, formulas not getting interpreted properly).
I have verified all data being returned is in the same format, collated the same, checked the schema for any changes, I have uninstalled and reinstalled Crystal Reports dependencies. When I run connected to the old databases it works fine, when I change my connection string to the new databases it does not work properly. I have looked on the Crystal Reports Forums and help documents and have found no reason for this to happen.
Question: does anyone know, or has anyone encountered this issue with upgrading SQL Server versions? Any possible explanations on how to fix it, without rewriting the application to use a newer Crystal Reports version? (our VB6 legacy application is irreplaceable)
There may be some inconsistencies from sloppy upgrades. I use the term "sloppy" loosely; I do things sloppily sometimes too. Here are some tips:
http://thomaslarock.com/2014/06/upgrading-to-sql-server-2014-a-dozen-things-to-check/
we have three SQL servers serving a variety of applications on different webservers.
Each application is using reporting services functionality.
The average load per server per month is about 40.000 reports, taking an average of 3.1 secs to deliver a report.
At this moment the the situation is as follows:
Application A has his database on SQLServer A and is using Reporting
Services on SQLServer A. (SQL 2008)
Application B has his database on SQLServer B and is using
Reporting Services on SQLServer B. (SQL 2008R2)
Application C has his database on SQLServer C and is using
Reporting Services on SQLServer C. (SQL 2008R2).
We have just bought a new server, runnning SQL 2012.
Would it be wise to move all reporting to the Reporting Server 2012?
My idea is that there would be a significant performance-gain. Also, There would be only one reporting server to manage. But is that so? Are there penalties when running reports on one server while the database feeding the reports is on another server? Is it a problem if the Reporting Services version is different then that of the database server?
I would like very much to hear your thoughts on this.
Performance and manageability are two key-components.
Greetings and thanks for thinking with me,
Henro
Are you using the Enterprise Edition of SSRS 2012 (so that could take advantage of scale out via deploying parts of the SSRS implementation on different servers)? Here's a SSRS 2012 feature list by edition. Also, are you using any scheduled (i.e. snapshot or scheduled delivery) of reports to balance the load requests?
I recently changed my compatibility mode of my sql server 2005 form 2000 to 2005.
Is there a utility that can scan my sp and functions and tell me if I have any compatibility issues?
I am not sure if it works from inside sql 2005; but if you still have a sql 2000 server then MS have an upgrade advisor that will report on your code. If you don't scripting out all the objects and trying to run them back into a new database set as sql 2005 mode is a fairly good way to test the migration.
Depending on your application be careful just switching there are syntax differences and connection options that changed between 2000/5 beyond just stored procedure changes. If your application runs sql queries natively (not sp's) then the application may have compatibility issues beyond just the internal database code.
We run SQL Server 2005 exclusively for databases that we use (I'm trying to push to get them upgraded, but alas!). On the client side with Management Studio, are there any benefits to upgrading to SSMS2008 when only connecting to SQL Server 2005 databases? I've seen that Intellisense won't work, so I'm curious if it's worth the hassle.
Yes, there's quite a few improvements intellisense is definitely a big one for developers (Intellisense only works against SQL Server 2008 databases, unfortunately), but there are also other things like T-SQL Debugger, Activity Monitor, the Object Explorer Details
Also, multi-server queries, and the ability to color the connections (get a visual clue whether you're on dev, test or prod system) and a lot more.
See some good background info here at Simple-Talk.
It is up to you. My favorite is search feature. See link for details.
Having worked with SQL 2005 since it came out, upgraded my client tools to 2008 when it came out, and still not upgraded our server, I don't think it is worth upgrading, especially if you aren't moving to SQL 2008 on your server anytime soon. There is no real harm in upgrading, but you need to get familiar with a slightly different tool that IMO is neither worse nor better.
There are a lot of things to like about SQL2008 SSMS, even if you are connecting to SQL 2005 servers:
Customize the columns in the object views, including some very useful ones like DB size
When viewing a query execution plan, it will list any indexes that it recommends
Color-code server connections
Execute SQL statements against multiple servers
In our environment, we have a mix of SQL 2000, 2005, and 2008 servers, so I still use SQL 2005 SSMS to connect to all three (The new "Activity Monitor" in SQL2008 SSMS doesn't work for SQL 2000 servers.)
I don't want to sound like taking sides, but Toad 4.6 rulez! :-)