I'm developing a project with ASP.net-MVC and as it's Model first, it generates the .mdf and .ldf files of database automatically. and database is in version of 2014. when I wanted to upload it on host server they told me that they don't support upper version of 2012. so I need to migrate my data base from 2014 to 2012 version.
my data base is not that much big. and I follow this article
https://www.mssqltips.com/sqlservertip/2810/how-to-migrate-a-sql-server-database-to-a-lower-version/
step by step but no diffrence happend to my database version. its still Product Version:12.0.2000.8
really appreciate you'r help. thanks
You develop the database based on the Model First, so you have all control in generation /modifying the database.
You needn't to migrate the database, but in visual studio you can re-generate the database in sql server 2012.
To Generate the database in sql 2012, do the same steps you follow to generate database for sql 2014 in visual studio, just for reminding:
In the EDMX design surface, right click ->Generate database from the model
Follow the wizard and create a new connection to sql2012.
At end of the wizard, a new database is created in sql server 2012.
Sql script is also auto generated named e.g. model.edmx.sql including all DDL of the Entity and associations,...
Exute that script within VS, you can select the connection and executing the script in the new database server 2012.
For the data, you can use the bcp utility or the export wizard in SSMS.
Update:
In the Model First approach, you create a diagram that will be automatically converted to a coded model and the model is saved in EDMX (xml file).
If there is no EDMX in the project, it means that you didn't use the ModelFirst approach, but you may used a template of MVC project which auto generate database at the start of the project.
The benefit of the Model First is the ease of change and sync between development Environment and the production for future changes.
You can re-engineer your project and add ModelFirst approach even you created a database.
From there you can re-create the database in the sql server 2012.
I describe step by step tutorial to build your mode:
Building DataModel from Existing Database in EntityFramework 6 For ModelFirst Approach
Compatibility Level should be set to SQL Server 2012(110) before to following the steps https://www.mssqltips.com/sqlservertip/2810/how-to-migrate-a-sql-server-database-to-a-lower-version/
To change the compatibility level go to database properties->Options->Compatibility Level
When you run the output script, it should be run on the target server (2012). Backups on recent versions cannot be restored on earlier versions.
Take a look here
The setup will change your database from 2014 to 2012.
Related
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 am working on SQL Database Project in the Visual Studio 2017. Purpose is to push only the Stored Procedure Changes to VSTS Git.
Instead of connecting to the Database from the Project Solution, I am using Import SQL Scripts.
In this approach, any changes in the stored procedure has to be copied and pasted on the stored procedure in the Project Solution.
How to set the SQL Database Project in the Visual Studio 2017 connected to the Database? And Connecting to the Database should not allow Import option to extract the all other database objects such as Table, View from SQL to Visual Studio. We do not want all other scripts. We just need only those Stored Procedures to be sync with database environment.
At present, we are making the changes to the Stored Procedures in the SQL Management Studio. Further then, we manually copy the SQL Script from SQL Management Studio to Visual Studio Environment.
Whether, will it be possible for us to have the changes auto-sync between SQL Management Studio to Visual Studio (or) by refreshing the Visual Studio Project.
In Visual Studio, go to Tools -> SQL Server -> Schema Compare. At the top of the new window, access the dropdown, and put your local DB connection (where you've added the stored procedure) on the left, and your DB project on the right. Hit Compare, and then Update. This should update the dbo directory in your Database project to match the local db schema, whether you're adding 1 proc or 100.
At this point, you'll also need to add a reference to the stored procedure to your database project in VS. Put the .sqlproj into a text editor, add the reference (there will be lots of examples to copy; it should be easy), save, and build the project to make sure you got it right. git add, commit, and push!
This only works if the schema of your local DB matches what is in the VS project. If you want to copy something from a database with a different schema, I think you're stuck copy-pasting.
AFAIK, there is no way to automate this, but I would love to be corrected about that. It would save me so much time at work. :)
Migrating a 2003 SharePoint farm from an old SQL Server 2005 install to a SQL Server 2012 install on a separate server.
We recently lost our SharePoint expert, so since me the DBA uses Microsoft products it shouldn't be that much of a leap right?
I can't for the life of me find the actual farm database configuration in SharePoint. I will need to change the connection string(if it uses such a thing) to point to my new database server after I detach and attach the database files.
It might be better to move the content databases over, and then re-run the SharePoint Technologies Wizard and create a new config database. Once done you can recreate the applications and re-add the content databases. I have had to do this after upgrades / failed patches, config corruptions etc. With an upgrade, you will also want to run the tool again to update the database schemas to the latest version.
When I create a new ASP.Net MVC 4 project with Visual Studio 2012 it puts the data in an mdf file in the project directory.
What I would like to do at this point is to migrate the database to an SQL Server instance gently, keeping all the scaffold stuff provided by the ASP.Net MVC 4 project template (I mean user accounts management etc.)
What would be the right step-by-step way to do this?
How exactly should I change the connection string?
How should I authentify my application in SQL Server in production?
Sorry for a dumb question but I haven't dealt with ASP.Net applications before, in my previous experience (which was with WinForms) all the actual users had a separate SQL Server account and it was pretty straightforward.
The whole User Instance and AttachDbFileName= approach is flawed - at best! Visual Studio will be copying around the .mdf file and most likely, your INSERT works just fine - but you're just looking at the wrong .mdf file in the end!
The real solution in my opinion would be to
install SQL Server - Express (and you've already done that anyway) or any other edition
install SQL Server Management Studio (Express)
create your database in SSMS Express, give it a logical name (e.g. YourDatabase)
connect to it using its logical database name (given when you create it on the server) - and don't mess around with physical database files and user instances. In that case, your connection string would be something like:
Data Source=.\\SQLEXPRESS;Database=YourDatabase;User ID=AppUser;Pwd=Top$ecret
and everything else is exactly the same as before...
For deployment to production, you basically have a number of options:
create deployment SQL scripts yourself and have them executed using sqlcmd or any other useful SQL script runner
use a SQL diff tool like Red-Gate SQL Compare or even the built-in Visual Studio diff tool to determine difference between the database version installed at your client's site, and the new version, and create a single upgrade SQL script from that diff
use the Visual Studio Database Projects and let VS handle the upgrade scripts and deployments. VS database projects craft a model on top of your database - you basically only ever create the CREATE TABLE .... script and the VS tools figure out what needs to be altered, dropped, created fresh
if you're using Entity Framework code-first - look into using the EF code-first migrations to update your database from C# code
What I did is just move the mdf and log file and attach them via SQL Server management studio
The connectstring can be quite simple, something like:
<add name="DefaultConnection" connectionString="Server=YourServer;Initial Catalog=YourDatabaseName;Integrated Security=SSPI;" providerName="System.Data.SqlClient" />
I am used to using Oracle Designer by creating database object definitions, then creating DDL SQL required by connecting to a database instance.
For eaxmple, when adding a new column to a table, first I add it to the table definition, then generate the DDL SQL against the development version and run it, then after testing I point to the Production instance to create the missing column in Production.
Given that there is no Designer in SQL Server what is the correct procedure to say add a column to both database instances? Is there a tool for keeping the schemas in sync?
RedGate offer a product called SQL Compare, that can be used to script out the differences between different databases.
See: http://www.red-gate.com/products/SQL_Compare/index.htm
You could also use the Database Diagrams within SQL Server Management Studio to design your database schema however this would be constrained to within a given database.
There isn't a built in tool for keeping them in sync (that I know of), but RedGate has some commercial apps for this.
What do you mean there is no designer in SQL Server? Are you using SQL Server Management Studio?