What is the best way to use SQL Server 2008 as a development database, but ensure that the database is compatible with SQL Server 2005?
This can be done via SQL Enterprise Manager or like this:
ALTER DATABASE <database>
SET COMPATIBILITY_LEVEL = { 80 | 90 | 100 }
Use 90 for 2005 compatibility.
This replaces the functionality used for previous releases, the stored procedure sp_dbcmptlevel.
You can set the database compatibility level, but there is no guarantee that this will cover all your bases. For example the new data types will be available on the SQL 2008 system, but they won't be available on the SQL 2005 server.
The only way to guarantee that everything will work from Dev to Prod is to put SQL 2005 in development.
Don't forget that there are also behavioral differences between the two versions, and something on 2008 may perform differently (and insufficiently) than 2005 all other things equal - this will obviously depend on a lot of factors about your data and application.
You're better off developing against the lowest common denominator and testing against the newer versions.
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.
We are updating several SQL Server 2008R2 instances to SQL Server 2012 SP3 CU2. I know that the database versions will be changed from 100 to 110 during this process (e.g. once finished, the databases can no longer be moved back to a 2008R2 instance).
Does this change to the databases occur during the upgrade itself or the first time that the databases are brought online when the server restarts?
SQL server keeps track of version in two ways. First, your SQL Server instance has a version (for example SQL Server 2008 R2 is 10, followed by some decimals to keep track of patches).
Your databases are a separate version, known as a Compatibility Level. If you upgrade your instance, your databases will not be upgraded until you choose to do so. That does not mean there will not be an impact, however it does mean those databases can remain in their old version. Your example of 100 and 110 are both Compatibility Level.
Please see changing Compatibility on MSDN here: https://msdn.microsoft.com/en-us/library/bb510680.aspx
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 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.
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.