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
Related
We are migrating the current SQL Server 2008 to SQL Server 2016 and we need a SQL server query to find the below objects and the syntax
Stored Procedures
Triggers
Functions
Tables
Indexes
Views
That will be incompatible with the current SQL Server 2016 so that we can modify them accordingly
You can look here:
https://learn.microsoft.com/en-us/sql/database-engine/sql-server-database-engine-backward-compatibility?view=sql-server-2017
It is highly unlikely you are using any of the features that were removed in your actual objects (tables, views etc.) as they mostly relate to administration... You can always just set the database compatibility level back down (in fact depending on how you are upgrading/migrating it probably will be set appropriately anyway)
Whenever you want to migrate the database from one server to another or lower database version to higher version then you should do with .bak file or with .sql script file of your database.
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
At home, I have SQL Server 2008 R2 (Express) installed which is attached to a certain .mdf file. I'm in the process of installing SQL Server 2012 (Developer Edition). Can I attach 2012 to the same .mdf file? Logically, it seems like this would work as long as only one of the two instances of SQL Server is running. Thoughts?
You can go upwards - from an older version to a newer one, e.g. you can backup your database in 2008 R2 and restore that backup in your 2012 instance - but 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.
Also: since the internal file structures of the .mdf are very much different and specific to each version of SQL Server, you will NOT be able to use the same .mdf from two different SQL Server versions. That definitely won't work.
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.
It might work - but I believe you're going run in to some issues later down the road if the SQL 2012 updates the file in a technical manner that SQL 2008 blows up on.
Wouldn't it be simpler to run one copy and back up and restore to the other?
I have a database deployed on a testing machine and a production machine. There is some data (columns of a table) in the testing database that I would like to copy over to production.
When I try to restore a backup onto the production box I get the following error:
System.Data.SqlClient.SqlError: The database was backed up on a server running version 10.50.1600. That version is incompatible with this server, which is running version 10.00.4000. Either restore the database on a server that supports the backup, or use a backup that is compatible with this server. (Microsoft.SqlServer.Smo)
Is there an alternate way to get the data into the table?
This answer ONLY if you need the data (from here: http://sqlserverlearner.com/tag/the-database-was-backed-up-on-a-server-running-version-10-50-1600-that-version-is-incompatible-with-this-server):
Script the object you want (table and data) under tasks, generate scripts, select the object, and make sure to include all the data (possibly the schema as well). Take this to a new query window and save the SQL file, then execute it on your other server.
You could
Generate INSERT statements for the data in question
Create a linked server from the test to the other server and run sql statements against that
Upgrade the target server to 2008 R2 (this is not something to take lightly)
You should keep your environments at the same version / rev. SQL Server restores are not backward compatible.
Use generate scripts with data, you can select the version of MSSQL. Then run the outputted SQL on the server you want it.
Ideally you'd upgrade your production server to match your test environment, otherwise your tests may not always be representative.
If they are different versions though, you can't restore a database to an older version of SQL server, you should either use the generate scripts command to create the new table and insert the data, or use a tool like SQL compare/Data Compare from RedGate which will do all of this for you.
This is the problem with the sqlserver version mismatch while restoring the database. It means It couldn't possible to restore the database server 2008 to 2005. It wouldn't support higher version to lowerr version.
The following options are available,
You can link the servers and move the table from one server to other server
Generate the sql script and execute in the target database
Use the below URL to generate the insert script and execute generated script into target server.
http://www.codeproject.com/Articles/5598/Generating-INSERT-statements-in-SQL-Server
you can use redgate toolbelt tool kit to sync data between different version of sql server or sql server to sql azure or sql azure to sql server database . it is very very easy to use .
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.