# Downgrading from SQL Server 2008 to 2005

Database files that are built using SQL 2008 are not compatable with 2005. Is there a work around?

-
Don't forget to also export the server logins. –  StanleyJohns Apr 15 '11 at 3:22
Is this because you are developing in 2008 but your production servers are still 2005? Any solution you provide is just going to delay the inevitable while at the same time making your life miserable, as you will likely end up doing these downgrades on a regular basis. –  datagod Nov 8 '11 at 19:49

No 3rd party tools necessary. SQL Server 2008 Management Studio gave us a very powerful tool to down-convert a database because they added a "Script data" option to the "Script database" wizard.

Just right-click the DB in SQL2008 SSMS, and go to Tasks, then "Generate Scripts"

Walk through the wizard, make sure to chose "True" for "Script Data" under the table/view options. Choose all objects, then run the script it creates on the 2005 server. (Please keep in mind that the script created could be massive if the original database is very large!)

Note that you can even run the wizard against a SQL2005 server to down-convert a SQL2005 database to SQL2000 (you would need the 2008 tools installed on your workstation, of course).

-
No offense, but this can't be a solution if the database is big. Try that technique on any table with few millions rows (and think of varchar(max) as the data type of a single column) and if Management Studio will be able to open and parse this file you'll be happy, but I'm sure it won't open, it will crash. Sorry, but that's not the solution to this problem, except if the db is really small. –  Marian Feb 4 '11 at 16:36
Sure, if the db is too large, script out just the database structure, then use your favorite method (SSIS, BCP, Import Wizard) to push the data. –  BradC Feb 7 '11 at 18:13
In SSMS 11.0 there appears to be no option to script data along with the structure. i.imgur.com/SGkG8oZ.png –  jcollum Nov 11 '14 at 22:30
Ah OK it's now under "Types of data to script" just above Table/View Options –  jcollum Nov 11 '14 at 22:39

You could BCP the data from one SQL Server instance to another instance. That would be the fastest way to copy the data from one version to another. Depending on the volume of data, it might take a long time.

-
Depending on the volume of data it will almost always take a long time –  jcolebrand Jan 5 '11 at 5:45
Yep, it sure will. Moving a large database to an older version of SQL Server isn't an easy task. –  mrdenny Apr 15 '11 at 7:32
The upside to BCP is that it's going to be faster than using script data. Yes, it's slow, but it's faster than many alternatives. –  Jeremiah Peschka Apr 16 '11 at 22:27

There is no direct way, that I know of, to downgrade a DB from 2008's format to 2005's unfortunately.

The way I have done this in the past (actually with older versions of SQL server, but the process will be the same) is:

1. Restore the DB on a SQL2008 instance if not done already
2. Build an empty DB with the correct structures (tables, indexes, constraints, views, procs, triggers, ...) on a SQL2005 instance. Hopefully you can do this from your existing build procedure and/or source code, but if not you can use SQL Server Manager to create scripts for everything in the 2005 DB and run the result on a blank one in the 2008 instance.
3. Ensure the two instances can see each other (i.e. there are no firewalls blocking connections if the instances are on different machines) and link them using sp_addlinkedserver.
4. Copy all the data over from one DB to the other. If there are no foreign key constrains and similar issues in triggers to worry about you can just link the DBs together and cursor through the list of tables (selecting them from sys.objects) and running
INSERT destinationserver.destinationdb.schema.table SELECT * FROM sourcedb.schema.table
(or INSERT schema.table SELECT * FROM sourceserver.sourcedb.schema.table if you have linked the instances that way around)
for each table. If you do have inter-table consistency enforcing constraints and triggers you will of course need to a be a bit more clever about the ordering of these operations, especially if you have cyclic constraints like a table with a constraint based upon itself (one holding hierarchy data, as a possible example).

It may be more efficient to just copy the data first and add all the other structure (indexes, procs, triggers, ...) after step 3. This avoids row insert ordering issues caused by constraints and triggers, and building the indexes at the end should in theory be quicker than building them as all the data is added - though if you have any clustered indexes on your tables create these before adding the data as they would not be faster to create after the fact.

Of course this all assumes that none of your objects use SQL 2008 specific features - if they do you will hopefully find out and fix such things when things error upon rebuilding the schema. If any of your code relies on officially undefined behaviour that happens to have varied between SQL Server versions you may have some much more subtle and elusive bugs to hunt down and iron out later.

-
-1 because this is actually inefficient (select * into from) compared to the likes of BCP. –  jcolebrand Jan 5 '11 at 5:46
@jcolebrand fair enough on efficiency. Though the technique is one that I've had work. –  David Spillett Jan 5 '11 at 10:06
it's a fair system, I just thought I would include that on account of future readers here. You've got the upvotes currently for it not to be an issue. ;) –  jcolebrand Jan 5 '11 at 15:15

I faced similar situation and used Database Publishing Wizard to script schema and data for SQL Server 2005 from SQL Server 2008 database.

## SQL Server Hosting Web Service (and toolkit)

### Database Publishing Wizard

-

You first have to script the database and make sure on the version you specify the type you want to down grade to. And to copy the data from the higher version to the lower version SQL Data compare will do you the trick for you.

Good luck!

-