We are using TFS 2013 and SQL Server 2014. A client of ours is requesting the TFS project and also uses TFS 2013 but with SQL Server 2012. How can we go about migrating? Will a simple backup and restore work when downgrading from 2014 to 2012?
You CANNOT do this - you cannot attach/detach or backup/restore a database from a newer version (like 2014) of SQL Server down to an older version (SQL Server 2012) - the internal file structures are just too different to support backwards compatibility.
And no - setting the compatibility level to 110 (for SQL Server 2012) in SQL Server 2014 also doesn't help ; it will prevent your T-SQL code from using new SQL Server 2014 T-SQL features, but it does not change the internals of the database file in any way, shape or form.
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.
Update by #MrHinsh:
WARNING: While these options may work for your own database projects it will NOT work for TFS. Changing the Database schema, moving data, or editing the tables will BREAK TFS and will invalidate your support agreement with MSFT
Backup / restore isn't a viable approach here - no version of SQL Server knows what was changed in the database files' formats for the next version.
So copy database schema and data from 2014 to 2012 and pray it will work - chances are, it wouldn't. There should be an Import / Export wizard in SSMS, at least it was there before.
Related
We have several SQL Server databases at work and we plan to keep all of them in a Database Server. However, while we use SQL Server 2014 in some of the databases, there is also a database (let's say ABC) with the version of SQL Server 2008 R2.
The problem is that; ABC is a database originated from another company and sometimes it is updated by them using scripts, etc. So, this means that we have to go together with the version they use. As far as I know, it is possible to restore a database of version 2008 R2 in the version of 2014 but the reverse operation is not possible (to restore a database of version 2014 in the version of 2008 R2).
So, in that case what is the best way to solve this problem by using the single database (SQL Server 2014) on the same server?
You can generate database from the 2014, 2008 compatible. You can dig into the advanced option and you will find creating scripts for triggers, indexes and all dependent objects.
Generate Scripts
Choose Compatibility
Specify Data generating scripts
The server could be 2014.
You just need get SQL Server Management Studio (SSMS) version 2008 and generate backup using it.
You could have lots of SSMS versions.
I'm planning to migrate all the SSRS reports from 2008R2 server to new sql server 2014 environment. As far as migration is concerned, I was asked to take the backup of 2008R2 report server database and restore it in 2014 server.
I was not convinced with this since there may be new tables available in 2014 Report server.
The new features of 2014 cant be utilized if the old report server database is restored.
Please let me know if this thought is correct.
Are there any new tables available in 2014 report server database?
What is the best option to migrate ssrs reports from 2008 r2 to 2014 server?.
Your question is a bit confusing, I will assume you want to move the database from a Server A with SQL Server 2008R2 + SSRS 2008R2 to a Server B with SQL Server 2014 + SSRS 2014.
Are there any new tables available in 2014 report server database?
There is no official communication on it.
If you really want to know it you could do a schema compare between the 2 versions.
But do not forget to compare everything, not only tables:
Columns
Stored Procedures, Functions
...
Database structure is not the only thing to take into account, what about:
All the configuration files
Encryption Keys
...
What is the best option to migrate ssrs reports from 2008 r2 to 2014
server?.
Short answer:
My recommended way of doing it would be to use RS Scripter and generate a script on Server A with all the objects (reports, datasources, subscriptions, ...) you want to move.
Then you can restore it on Server B.
Long answer:
If you really want to migrate the full database like you were asked to do, there is no officially supported way to move the database to another SQL instance and upgrade the version at the same time.
You could try to follow the steps to Backup and Restore Operations for Reporting Services, and apply it to a newer SQL Server instance with another SSRS version, but it will be at your own risk.
The supported ways to do would be to either:
Upgrade from SSRS 2008R2 to SSRS 2014 on Server A
Move from Server A to Server B
or
Move from Server A to Server B
Upgrade from SSRS 2008R2 to SSRS 2014 on Server B
Here are the related MSDN articles for these operations:
Migrate a Reporting Services Installation (Native Mode)
Upgrade to SQL Server 2014
Again, I would advise using a tool to migrate the reports and other items instead of trying to migrate the full database.
I do not think restore 2008R2 reportserver db on 2014 will work, because the report definition schema is totally different.
I did a migration task to move 2008R2 reports to 2012. Because there are hundreds of reports on the 2008R2 server, I found the easiest way is to write some codes to read report definition, and then create on 2012 server.
From: https://msdn.microsoft.com/en-us/library/ms143747.aspx
There are two general approaches to upgrading a Reporting Services
deployment:
Upgrade: You upgrade the Reporting Services components on
the servers and instances where they are currently installed. This is
commonly called an “in place” upgrade. In-place upgrade is not
supported from one mode of Reporting Services server to another. For
example, you cannot upgrade a Native Mode report server to a
SharePoint mode report server. You can migrate your report items from
one mode to another. For more information, see the ‘Native to
SharePoint Migration’ section later in this document.
Migrate: You
install and configure a new SharePoint environment, copy your report
items and resources to the new environment, and configure the new
environment to use existing content. A lower level form of migration
is to copy the Reporting Services databases, configuration files, and
if you are using SharePoint mode, the SharePoint content databases.
If you do an in-place upgrade from SQL Server 2008R2 to SQL Server 2014, then everything should work as expected.
Are there any tools to convert SQL Server 2014 database to 2012?
I tried Generate Script but the generated script with data is too large and SQL Server Management Studio did not execute it, I need to have both schema and data.
To my knowledge, there are basically three two options for migrating a database to a lower version of SQL Server, without using 3rd party tools:
Generate Scripts (not really suitable for large amounts of data)
Custom Scripting and BCP or Import/Export Wizard
SQL Server Integration Services (Transfer Database Task)
First option is not suitable in your case, as noted.
Second option is to simply script the structure of the database, and then use the Import/Export Wizard to copy the data, one table at a time. Note, that if you have foreign key constraints in your database, you might want to disable the constraints until after you have populated all your tables with data. This blog post explains in details how this can be done.
Third option uses the SISS Transfer Database Task which basically uses SMO to create the objects on the destination server and then transfers the data. This is the recommended way of migrating a database between SQL Server instances of different versions. SSIS requires that you have installed SQL Server Data Tools - Business Intelligence (SSDT-BI) for Visual Studio. Before SQL Server 2012, this was called Business Intelligence Development Studio (BIDS). You can download these here:
Microsoft SQL Server Data Tools - Business Intelligence for Visual Studio 2013
Microsoft SQL Server Data Tools - Business Intelligence for Visual Studio 2012
If you don't have Visual Studio, SSDT-BI / BIDS is included in the SQL Server installation.
Use the script, but instead of executing it trough Management Studio, use the lightweight sqlcmd utility.
http://msdn.microsoft.com/es-es/library/ms162773.aspx
Oh well, Dan's second option does not work: after installing SSDT-BI for VS2013 and configuring the Database Transfer Task it says that the version of the source database instance has to be lower or equal to the version of the destination database instance: so, a migration from 2014 to 2012 (or in my case 2008R2) is not possible.
I have installed SQL server 2008 R2 and i try to restore a database a colleague sent me in a .bak file.
Unfortunately, i cannot restore the database since the database was saved on a server from version 10.50.1600 and my SQL server version seems to be 10.00.1600.
I tried to upgrade my SQL server with SP1 and SP2 packs but it didn't change anything.
Otherwise, i noticed by clicking on the server property that the line "product" displays Microsoft SQL server Express edition even though i have installed SQL server 2008 R2. That's at least what is displayed when i fire it...
Can anyone help me ?
Thanks in advance
You CANNOT do this - you cannot attach/detach or backup/restore a database from a newer version (SQL Server 2008 R2 - 10.50.1600) of SQL Server down to an older version (2008 - v10.00.1600) - 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.
Understand, what the version numbers mean. You need to be on R2 which is not just a patch or service-pack.
I'm asking for the proper way, in SQL Server's T-SQL (I think that's what it is) code or using another language, to import data from a Microsoft Access MDB Database into a new SQL Server Database.
Now, typically I would just import it in. The problem is I'm writing a .SQL script (I could use another technology if needed) to do all this leg work as this will need to be done fairly regularly. Likely at least once a week, for about 5 months in the year.
To digress a tad, I had wanted to implement a single database and distinguish separate source database using something like a DatabaseID field, but the powers that be overthrew me there.
I was previously using SQL Server Management Studio 2012 with SQL Server 2008 running the T-SQL (on a production machine) that worked fine. I've now migrated to a local SQL Server Management Studio 2012 with SQL Server 2012 (for development) and the code that used to work doesn't anymore.
This code is what used to work: SELECT * INTO [dbo].[Controls] FROM OpenDataSource('Microsoft.Jet.OLEDB.4.0', 'Data Source=C:\Show.mdb; Jet OLEDB:Database Password=BobSaget')...[Control] The password has been obfuscated for security ...
That's likely a sloppy solution. What's the ideal way?
Thanks in advance!
I would recommend using Microsoft's SQL Server Migration Assistant for Access.
SQL Server Migration Assistant (SSMA) is a free supported tool from Microsoft that simplifies database migration process from Access to SQL Server. SSMA for Access automates conversion of Microsoft Access database objects to SQL Server database objects, loads the objects into SQL Server, and then migrates data from Microsoft Access to SQL Server.
SSMA for Access v5.2 is designed to support migration from Microsoft Access 97 and higher to all editions of SQL Server 2005, SQL Server 2008, SQL Server 2008 R2, SQL Server 2012, and SQL Azure.
You can find it here.
You may need to fix the structure after the migration as it tends to over exaggerate many of the data types.
Have you checked your DCOM security on MSDAINITIALIZE?
I had this problem when moving to a local instance of SSMS 2012.
http://blogs.msdn.com/b/dataaccesstechnologies/archive/2011/09/28/troubleshooting-cannot-create-an-instance-of-ole-db-provider.aspx