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.
Related
Reading official docs about STRING_SPLIT function, at the begining of the doc there is a note:
Note
The STRING_SPLIT function is available only under compatibility level
130 and above. If your database compatibility level is lower than 130,
SQL Server will not be able to find and execute STRING_SPLIT function.
To change the compatibility level of a database, refer to View or
Change the Compatibility Level of a Database. Note that compatibility
level 120 might be default even in new Azure SQL Database.
So, what does compatibility level mean?
Compatibility Level refers to the way SQL Server operates in relation to a specific version of SQL Server.
Let's say for example, you have an application running well on SQL Server 2012, but you need to upgrade to SQL Server 2019 because support is ending soon. Everything runs great on SQL Server 2012 and the application has not been updated in many years. So, it's unclear how it might perform running on SQL Server 2019, or if it'll even work at all.
To ease the transition when you migrate to SQL Server 2019, you could consider leaving the database in SQL Server 2012 compatibility level, to avoid any unforeseen performance issues that may be introduced by the way the SQL engine and optimizer work in SQL Server 2019. Essentially, to the application, it's as if you're still running SQL Server 2012.
Now, the downside is that you can also not take advantage of the newer features that have been introduced since SQL Server 2012, such as STRING_SPLIT.
I know that you can't (at least not easily) restore a SQL Server 2012 backup on SQL Server 2008. But how does it work for SQL Server 2014 to SQL Server 2012 ?
On database level there is the property to adjust the compatibility mode to any other SQL Server version.
How does this helps or work ? Will it only disallow the features from 2014?
To be honest I already tried to restore a backup, but 2012 didn't recognize the datafile, so I couldn't click ok Button to start the restore procedure.
Did I miss some important option ?
You CANNOT do this - you cannot attach/detach or backup/restore a database from a newer version of SQL Server down to an older version - the internal file structures are just too different to support backwards compatibility. This is still true in SQL Server 2014 - you cannot restore a 2014 backup on anything other than another 2014 box (or something newer).
You can either get around this problem by
using the same version of SQL Server on all your machines - then you can easily backup/restore databases between instances
otherwise you can create the database scripts for both structure (tables, view, stored procedures etc.) and for contents (the actual data contained in the tables) either in SQL Server Management Studio (Tasks > Generate Scripts) or using a third-party tool
or you can use a third-party tool like Red-Gate's SQL Compare and SQL Data Compare to do "diffing" between your source and target, generate update scripts from those differences, and then execute those scripts on the target platform; this works across different SQL Server versions.
The compatibility mode setting just controls what T-SQL features are available to you - which can help to prevent accidentally using new features not available in other servers. But it does NOT change the internal file format for the .mdf files - this is NOT a solution for that particular problem - there is no solution for restoring a backup from a newer version of SQL Server on an older instance.
Sure it's possible... use Export Wizard in source option use SQL SERVER NATIVE CLIENT 11, later your source server ex.192.168.100.65\SQLEXPRESS next step select your new destination server ex.192.168.100.65\SQL2014
Just be sure to be using correct instance and connect each other
Just pay attention in Stored procs must be recompiled
I have to run the backup of SQL Server 2000 in SQL Server 2008.
While restoring the database from the .bak file, I got the error
specified cast is invalid
After doing google I feel there is compatibility issue. Therefore I want to make the database compatibile to SQL Server 2000.
And run the below query
ALTER DATABASE DBNAME
SET COMPATIBILITY_LEVEL = 80
but nothing help. Any help will be appreciated.
You CANNOT do this - you cannot attach/detach or backup/restore a database from a newer version of SQL Server (like 2008) down to an older version (like 2000) - the internal file structures are just too different to support backwards compatibility.
You can either get around this problem by
using the same version of SQL Server on all your machines - then you can easily backup/restore databases between instances
otherwise you can create the database scripts for both structure (tables, view, stored procedures etc.) and for contents (the actual data contained in the tables) either in SQL Server Management Studio (Tasks > Generate Scripts) or using a third-party tool
or you can use a third-party tool like Red-Gate's SQL Compare and SQL Data Compare to do "diffing" between your source and target, generate update scripts from those differences, and then execute those scripts on the target platform; this works across different SQL Server versions.
Changing the compatibility level will get you closer to SQL 2000 but there were breaking changes (more likely they came in when 2005 did), unfortunately you will need to find where you get things that break and manually fix them.
Ed
I have a database which was upgraded from 2000 to 2005. Is there any issue using sp_dbcmptlevel to change compatibility level to 90. Will this cause any issues with old queries or stored procedures
Did you run the SQL Server upgrade adviser on the old database? It will tell you if there is any obvious problems. Be sure to test on a development database.
Here is the tool
http://www.microsoft.com/downloads/details.aspx?FamilyID=1470e86b-7e05-4322-a677-95ab44f12d75&displaylang=en
I am using SQL Server 2008 express edition but I want to make my databases still in 2005. How can I set it up to only show features that a 2005 database can use?
Like for instance I don't remember there being a "date" type. I only remember "dateTime".
I don't want to be using features that 2005 can't support and I later on upload my db to the my hosting site that uses 2005 still and find out I am using things not supported by it.
You won't be able to upload the database, just a script of it. Even when in 90 compatibility mode, the physical structure of the database will be the 2008 one and the hosting site won't be able to load it.
Note that the compatibility level does not necessarily mean that the new features of SQL 2008 are not available, but instead it simply means that (some) features that existed in 2005 will work the same way in 2008. The complete list of compatibility mode changes is on MSDN. In particular there is nothing to prevent the usage of a datetime2, date, time or any new time in a database set at compatibility level 90. In fact such would be impossible simply because the the compatibility level can be changed after a table is created.
You are going to either develop against a SQL 2k5 instance, or read the product manual and learn what features are available in what version.