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.
Related
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.
We are looking to replace SQL SERVER replication.
Today we've got several version on SQL installations because SQL replication does not support working with different SQL versions (2005 and 2008 for example), so instead of having several installation of SQL version (2005,2008,2012 etc...), we are looking install a single version on the server (let's say 2014) and using this version to replicate between all our clients (2005+).
Today we are using transnational and merge replication at the same time for each database.
I would like to know:
Is there a way to make different version replicate with each other?
Is there and good tool that can replace that replication?
SQL Server 2014 supports replication with SQL Server 2008 and on. https://msdn.microsoft.com/en-US/library/ms143550(v=sql.120).aspx
So if you use SQL Server 2012 as backend, SQL Server 2005, 2008 and 2012 clients are supported.
We are using transnactional replication between 2012 and 2016 and 2014 and 2016. For us the trick was to create a publisher on the older version and a pull subscription on the newer version. The only other thing to watch out for is you need to manage the relationship in SSMS using the older server as trying to go to properties from the 2016 box will throw an error.
I saw something about changing data types or another server setting that would eliminate the errors so it might be worth looking around.
I have a server running SQL Server 2008 Enterprise version which has a lot of SQL Codes and I want to upgrade it into SQL Server 2014 Enterprise version. But I don't know what will happen after I upgrade the SQL Server. Will there any SQL Code go unavailable/error? Will it run correctly after upgrading?
SQL Server 2008/2014 is a tool. It has got nothing to do with data/procedures/views etc. Data for SQL Server is stored in the form of .mdf files. So, no, your data or procedurers wont be touched. But yes lot of features are going to be deprecated in SQL Server 2014 when compared to SQL Server 2008. Full list is here. You should go through the list and find a suitable replacement for every deprecated item before migrating.
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 have a problem with my website. When I publish my site on server, I got an error message:
The database '----------------------------.MDF' cannot be opened because it is version 655. This server supports version 611 and earlier. A downgrade path is not supported.
What can I do about this?
You can't push a 2008 mdf file into a 2005 server. It just won't work. The problem is that sql 2005 has no idea what features you may have used in the 2008 database which doesn't exist under 2005.
Your only real option is to:
1. Create a blank database on the sql 2005 server.
2. Script your tables, views, procs, functions, etc from the 2008 server.
3. Run that script on the 2005 server.
IF you used some advanced features, then the 2005 server will not be able to run the script. Fix what you have to.
Yes... in SQL 2008, generate scripts for your DDL and DML; the vast majority of the scripts will be compatible, but you may need to make the odd tweak to accommodate SQL 2005.
Upload and run on your SQL 2005 instance...
There maybe a number of 3rd party tools that can aid you, particularly to generate the insert statements.
If your DB is particularly large, you might want to is SSIS to move the data across.