So I'm experiencing the issue described in the title.
I know SQL 2000 doesn't support MARS (Multiple Active Result Sets) but my clients have SQL 2005/2008 and some of them are still having problems when I use MARS because their databases came from SQL 2000.
There is any workaround for MARS in this cases?
ps: I'm terrified just thinking of not using MARS
Related
The following article states that SSRS 2016 supports SQL2008 and beyond for its ReportingServer DB: https://learn.microsoft.com/en-us/sql/reporting-services/install-windows/ssrs-report-server-create-a-report-server-database
However, I couldn't find any article specifying the supported database versions for SSRS 2012 - Does anyone know if running SSRS 2012 is supported with a SQL2005 database?
Many thanks,
Paul
We are planning to migrate from SQL Server 2000 to 2012. I understand this has to be done this way.
SQL Server 2000 -> SQL Server 2005/2008 -> SQL Server 2012
We first tested with SQL Server 2008 R2, but it has to be run under compatibility mode 80 due to some issues with some some stored procedures written using non-ANSI standard joins (eg. *= for LEFT JOIN). And I understand that SQL Server 2012 does not provide compatibility option for SQL Server 2000.
So I have to rewrite the stored procedures/views/functions in ANSI standard. But my question is how do I identify all the compatibility issues that would arise as a result of this migration? It is very difficult to go to each corner of the system and check. Are there any tools available to report the problem areas. or what is the best way to do this.
I have been searching for the past few hours and many people advice to test the system on SQL Server 2012 first. Yes i will do that but my worry is if something pops up later which we miss today. What is the expert way of doing this. Or should we settle with SQL Server 2008 R2.
Many thanks
John
I'm working on a similar migration: from SQL 2000 to SQL 2014.
Same problems.
There is just one solution I found: a bridge machine.
Step 1: collect a trace on SQL 2000. Template: SQLProfilerTSQL_Replay.
Step 2: run the advisor of SQL 2008 on the sql 2000 database, it also can process the trace.
Step 3: attach your databases on the sql 2008 bridge istance. Copy datafiles and attach them, use backup and restore, or what you prefer.
Step 4: raise compatibility mode to 2008 (or 2008r2, not a big difference).
Step 5: run the 2012 (2014 in my case) advisor.
Step 6: take the upgraded database on a sql 2012 istance and raise them to the new compatibility mode.
Step 7: run some check script.
DBCC CHECKDB WITH DATA_PURITY;
On all your databases.
Some racomand also:
DBCC UPDATEUSAGE(db_name);
Also I suggest to update stats and so on.
The problem will be more complicated if you have full text indexes and so on, but you have to face one problem ad the time.
Step 8: test all possible applications in a test environment.
Step 9: scare your boss. Next time you dont' need to jump 12 years of tech. I understand you, really, same problem.
Extra: write me if you want to exchange opinions and troubleshoting. I'm working on migration now.
I need to dump a software to a clients server. The problem is that my software is using SQL server 2008 and the client is using SQL Server 2000. So could anyone please suggest how I can make the clients SQL server 2000 compatible with my queries of SQL server 2008?
Thanks for the suggestion
But my concern is that software is already developed with SQL server 2008, then is there any way to use it with SQL server 2000?
You should have developed your software against SQL 2000, or demanded your client upgrade to at least 2005. Did
you ask the client which version you would deploy to before starting development? That is part of standard requirements gathering.
SQL 2008 queries may or may not be compatible with SQL 2000 due to
many new features in 2005 and 2008. There is no shortcut.
At best, make sure to use SQL 2000 documentation from MSDN when writing queries. Use the lowest common denominator.
If you are supporting a product that must deploy to multiple SQL Server versions, you may consider using an ORM that supports SQL 2000. Checkout the Nuget gallery of ORMs: http://staging.nuget.org/packages?q=Tags%3A%22ORM%22 - I believe something simple like Dapper supports 2000.
At minimum you should set your SQL 2008 compatibility level down to 2000 during development.
http://msdn.microsoft.com/en-us/library/bb510680.aspx
ALTER DATABASE database_name SET COMPATIBILITY_LEVEL = 80
I recommend you setup a virtual machine, install the older OS that your client uses as well as SQL Server 2000. Otherwise there are unforeseeable differences.
Does the current iteration of fluentmigrator work with SQL Server 2012? Its not listed under the supported databases.
There is no official support for Sql Server 2012 yet. But it should work if you specify SqlServer2008 as the database type. The differences between Sql Server 2005, 2008 and 2012 are not so significant when using FluentMigrator (Sql Server 2000 is a different story). Some features like the new sequence object have no support so in the meantime will have to be run using Execute.Sql.
UPDATE: I tested FluentMigrator against Sql Server 2012 Express with database type specified as SqlServer2008 and it worked fine.
UPDATE: FluentMigrator now officially supports Sql Server 2012 and Sequences.
I have SQL2008 installed on my local machine and need to view/alter/select rows and tables from a DB on a remote server running SQL 2005. Will I have any problems doing this. I have seen some people talk about setting compatibility for certain things, but this seems to only be when using new terms for SQL 2008 that don't exist in SQL 2005 is this correct?
Thanks for any help.
I assume that you're talking about using SSMS 2008 to connect to 2005 databases. You shouldn't have any problems with this at all - and in fact you'll get some benefits. SSMS 2008 has search capabilities that weren't around in the SSMS 2005 version. You won't get the intellisense when connecting to 2005 databases, but most of the other improvements in 2008 will still work.
The 2 biggest reasons for me personally to upgrade to the 2008 SSMS from 2005 are the Search feature, and also the missing-index suggestions when viewing estimated query plans.
This will work with no issues. My entire development team is setup this way currently. You will lose some features (i.e. intellisense) but other than that, it will work.