I have a large database that has to be recreated onto an older SQL Server instance. The database was kept with Compatibility level setting that corresponds to the older server. I know, it doesn't guarantee full backwards compatibility, but the database schema was initially created and maintained with the older server version in mind.
Here's what I have tried:
backup -> restore; of course it did not work because a database backup cannot be downgraded when creating it on a newer server version (oh Microsoft, why Compat level doesn't also generate compatible backups?)
DACPAC -> for unknown reason it fails, claiming that it's missing some dependent objects (but they are present in the database)
generate schema scripts - on newer SQL Management Studio (tried v17 and v18) it fails with
Microsoft.SqlServer.Management.Smo.SmoException: Cyclic dependencies found.. On older SQL Management Studio (2008) it doesn't fail but generates a script with objects in wrong order, so that views are being created before tables referenced in views, and, of course, execution of such a script fails
Visual Studio Schema compare tool - fails with meaningless warning and leaves Update button disabled Cannot generate deployment plan due to an internal error: An error occurred during deployment plan generation. Deployment cannot continue.
Is there a working (preferably - free) solution to this problem? How to duplicate the database schema on an empty database on another server?
Source SQL server version: 2017
Target SQL server version: 2008 R2
Database compatibility level: 2008 (100)
Utilising IF NOT EXISTS constructs and batch separators (GO) allows you to run your script multiple times.
On the first attempt some objects may not be created but these errors will not prevent the rest of the script from executing.
Running the script multiple times, until no more errors are returned, will create all objects.
Disclaimer: comes from personal experience.
Related
I have SQL Server 2012 (64-bit) (MSSQL11)
running on Windows 2012 R2 (64-bit) (NT 6.3)
with .NET framework 4.0.
It has a database called db_X and since this is a live production database it is always running and stopping it is not an option.
This is the only SQL Server database server that I practically have.
I want to take a backup (i.e. a full backup) of db_X (which I know how to do) and restore that backup (that .bak file) under a different name (say db_Y) in the same SQL Server database server.
I created a new database called db_Y, then right clicked db_Y then went to Tasks --> Restore --> Database...
Then I gave the path to that .bak file (as source) and tried to restore it by giving db_Y as destination (with the option - overwrite the existing database i.e. WITH REPLACE)
But this is not working. It is giving an error.
It says restore of database db_Y failed. System.Data.SqlClient.SqlError: The file C:...\db_X1.mdf cannot be overwritten. It is being used by database db_X. Microsoft.SqlServer.SmoExtended.
But I still believe that this can be done using the Management Studio. Or at least using a script. (as this is a common requirement.)
Why is it trying to restore on db_X, when I have clearly given db_Y as my destination? Isn't this a bit scary as db_X is my live database (because I might lose some data)?
How is it possible to (have a copy of an existing and running database under a different name in SQL Server or in other words) restore a backup of an existing and running database with a different name in SQL Server 2012?
I am grateful if someone could kindly explain how this can be done using the Management Studio or at least using a script.
When you are restoring the database, you need to rename the database to something other than the name of the original:
And then click the Files section and makes sure the file names are different than the original database:
I can't attach my database. When I try to attach a database in SQL Server Management Studio, I get this error:
The database 'C:\FILES\ACCOUNTING.MDF' cannot be opened because it is version 904. This server supports version 852 and earlier. A downgrade path is not supported. Could not open new database 'C:\FILES\ACCOUNTING.MDF'. CREATE DATABASE is aborted. (.Net SqlClient Data Provider)
and I have tried these commands:
cd "C:\Program Files\Microsoft SQL Server\130\LocalDB\Binn"
SqlLocalDB.exe delete "MSSQLLocalDB"
SqlLocalDB.exe create "MSSQLLocalDB"
but it still has an error
You CANNOT do this - you cannot attach/detach or backup/restore a database from a newer version of SQL Server (v904 = SQL Server 2019) down to an older version (v852 which is SQL Server 2016) - 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.
The error message in the problem statement occurs because the SQL Server database files (*.mdf, *.ndf and *.ldf) and backups are not backward compatible. Backward compatibility is why we cannot restore or attach a database created from a higher version of SQL Server to a lower version of SQL Server. However, there are a few options that can help us to downgrade the database from a higher version of SQL Server to a lower version SQL Server. These options include:
Use the Generate Scripts Wizard in SQL Server Management Studio
Use SQL Server Integration Services
Create Custom Scripting and BCP
In this tip we will use the Generate Scripts Wizard in SQL Server Management Studio.
Here are the basic steps we need to follow:
Script the database schema and data from the higher version of SQL Server by using the Generate Scripts Wizard in SSMS.
Connect to the lower version of SQL Server, and run the SQL scripts that were generated in the previous step, to create the database schema and data.
In the next section, I will demonstrate the steps for downgrading a SQL Server 2012 database to SQL Server 2008 R2 database.
Steps to Downgrade a SQL Server Database Using SSMS Generate Scripts Wizard
Step 1 Script the schema of the OUTLANDER database on the SQL Server
2012 instance (IITCUK\DEV01) using the Generate Scripts wizard in
SSMS.
In Object Explorer connect to IITCUK\DEV01, right-click on the
OUTLANDER database, expand Tasks and choose "Generate Scripts...".
This launches Generate and Publish Scripts wizard. Click Next, to skip the Introduction screen and proceed to the Choose Objects page.
On the Choose Objects page, choose option "Script entire database and all database objects", and then click Next to proceed to "Set Scripting Options" page.
n the Advanced Scripting Options dialog box,
set Script for Server Version to SQL Server 2008 R2 (or whatever version you want)
under the Table/View Options, set Script Triggers, Script Indexes and Script Primary Keys to True
and set Types of data to script to Schema and Data - this last option is key because this is what generates the data per table.
Once done, click OK, to close the Advanced Scripting Options dialog box and return to Set Scripting Options page. In Set Scripting Options page, click Next to continue to Summary page.
After reviewing your selections on Summary page, click Next to generate scripts.
Once scripts are generated successfully, choose the Finish button to close the Generate and Publish Scripts wizard.
Step 2 Connect to the SQL Server 2008 R2 instance
(IITCUK\SQLSERVER2008), and then run the SQL scripts that were
generated in Step 1, to create the OUTLANDER database schema and data.
In Object Explorer connect to IITCUK\SQLServer2008, then in SQL Server
Management Studio, open the SQL Server script you saved in Step 1
Modify the script, to specify the correct location for the OUTLANDER database data and log files. Once done, run the script to create the OUTLANDER database on IITCUK\SQLServer2008 instance.
Upon successful execution, refresh the Database folder in Object Explorer. As you can see in the following image, the OUTLANDER database has been successfully downgraded.
Notes
There are a few things to be aware of when using this approach.
This solution creates one large SQL file that has the scripts to create the database objects and also INSERT statements for the data in the tables.
For a large databases, the SQL file can get very large if you script out both the schema and the data and could be hard to load into an editor. Also, you may get a memory related error message from the editor if the file is too big.
For large databases, around 1GB or more, if this approach does not work, then you should look at using SSIS to migrate the database or create custom scripts to script out the objects and BCP out the data for each of the tables. You can use this Generate Scripts wizard to just generate the schema without the data and use SSIS or BCP to export and import the data.
This approach works for SQL Server 2017 to SQL Server 2005. Some of the scripting options might be a bit different in newer versions, but the process is still the same.
Before just executing the script, you should review the script to make sure everything looks correct such as the path of the database files, database options, etc.
Also if you are using new functionality that does not exist in the lower version, SQL Server won't be able to create the objects and you will need to review the scripts that were generated and update the code accordingly.
For a very simple database this approach should work pretty easliy, but you might need to spend some time making some modifications to the script for a more complex database.
Below is a list of all of the scripting options. If you click on an item, the bottom part of the screen gives you a short definition of the option.
Next Steps
To avoid this issue, always make sure that you perform a full backup of the database before you upgrade the SQL Server and database to a higher version of SQL Server. In addition, be sure to thoroughly test the application prior to releasing the application to the users.
Consider this downgrade option as your last option to rollback from an upgrade because the time and storage needed can be very large.
With a very large database be sure you have sufficient storage to support the data needs.
Be sure to verify row and object counts as well as test your application before releasing to production.
Additional Resources:
Why Can't I Restore a Database to an Older Version of SQL Server?
SQL Server Database Engine Backward Compatibility
SQL Server Upgrade Tips
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 am running SQL Server 2012 and VS 2010 with SSDT (SQL Server Data Tools) installed. My dev DB uses stored procs, functions, CLR objects, etc. It has a snapshot of prod data of about 500GB.
I created SQL Server Database Project and then imported the database. This created all tables, views, procs and functions files under schema names. Great stuff -- now I can do a version control just like in other VS projects, create deployments, etc. So far, so good.
But, I am confused as to what my development process should be for changing/adding procs/tables under SQL Server Database Project. It appears that any changes I make are applied to some LocalDb/Projects database and NOT to my dev database.
Am I suppose to author all my objects in that LocalDb, then Build and deploy to my dev database via Publish? I am worried about my existing tables in the dev DB since if the publish process drops and recreates tables, I will loose my prod data snapshot.
What is the right development process to follow in SQL Server Database Project?
Think of the source database (in your case, your database project) as being the "to be" state after deployment. When a deployment is initiated, the executable (SqlPackage.exe) compares the source with the target and generates a difference/delta script to make the target look like the source. This is why we no longer have to specify CREATE or ALTER; the tool figures it out. To answer your question about ongoing development, you can develop either way. You can develop in the project files and publish them to a common Dev database (say, if you're on a team), or you can develop in the database with tools like SQL Server Management Studio (SSMS) and synchronize with the project files with a schema compare (I use the latter technique because I like SSMS).
For deployment, you'll have to have SSDT installed on the machine from which you execute the deployment (SSDT ships with SQL Server 2012 and later; I don't know about SQL Server 2008). You can create scripts to simplify deployment. You'll essentially call SqlPackage.exe (it lives in x:\Program Files (x86)\Microsoft SQL Server\nnn\DAC\bin) with an action and a source. I use Publish Profiles as well to take care of most command properties. So an example deployment might look like this:
SqlPackage.exe /Action:Publish /SourceFile:MyDatabase.dacpac /Profile:MyProfile.publish.xml
For more information:
SQL Server Data Tools Documentation
http://msdn.microsoft.com/en-us/library/hh272686(v=vs.103).aspx
SqlPackage.exe Documentation
http://msdn.microsoft.com/en-us/library/hh550080(v=vs.103).aspx
Make changes inside the VS DB project.
Deploy changes to localDB to test
Publish the database to your production server. I prefer to use Schema Compare to do this manually, but you can also publish the project via the right click --> publish menu (which will also create a publishing profile), or using command line arguments. The publish process won't drop and create tables (unless you tell it to drop & recreate the entire db).
Alternatively, in the project settings you can change the connection string to point to your production server (as pointed out in the comment). However, I recommend against this, as it will then attempt to publish to the production server every time you run a local build (F5).
I am unable to use my database project after migrating from VS2010 to 2012.
All scripts for the database objects in the project are connected to the automatically-created localdb database. I am not interested in localdb since the database is large and I maintain it in a full-blown instance of SQL Server 2008 R2.
I tried all possible settings in Tools-Options-Database Tools-Data Connections-SQL Server Instance name to no avail. After re-loading the projects, it always restores the same connection to localdb.
My problem is that I need to refer from one database to another. I do it with synonyms:
CREATE SYNONYM [pcg].[practice] FOR [PcgDb].[Portal].[practice];
This script is automatically linked to localdb and the PcgDb on localdb has no tables. Hence I an getting an unresolved reference error 71501.
I tried also all combinations in Add Database Reference, even added my instance of SQL Server to the localdb linked servers, still the same error.
When you first create the SSDT project, the first step should be importing the target database; at that time you can specify you live instance of SQL Server. You shouldn't need to "get rid of" the local DB, it should just be ignored at that point. Perhaps this is happening since you migrated an existing 2010 project? In that case I would suggest you just create a new Project and do the import from the live server.