Generate Scripts equivalent for Transact SQL - sql

Question

In SQL Server Management Studio, there is an option to 'Generate Scripts'. The way we currently transfer a 2008 sql server database to a 2005 sql server database is by generating the scripts and running SQLCMD on that sql script file to push to a local instance of 2005 sql server. I'm creating a C# program to do whole bunch of other tasks as well but I also need it to convert the 2008 database and move it to a 2005 sql server. Is there a Transact sql statement or an easier way to convert the 2008 database to a 2005 database? Thanks.

Answer 1

Your development deliverable should not be a database binary (the .MDF file), but a deployment script. You treat your database deployment and upgrade just like any other source file, place it under source control, have peer code reviews at check in etc etc. Modifying directly the .MDF and then reverse engineering to deploy it is just plain bad. The problem you encountered now is just one of the problems, and there are many more problems, specially around the issue schema changes done during an application version upgrade. See Version Control and your Database.
Now is true that the entire VS tool set is trying to guide you down the path of 'just edit your MDF in the VS Database Explorer and everything will be fine'. Nothing will be fine and one or more deployment meltdowns are just ahead in your life, but lets pretend that VS does a good thing.
You can automate the extraction of the current schema and deployment of it via 3rd party commercial tools like Red Gate's SQL Compare, or you can roll your own 'Generate Scripts' fairly easy. SSMS all it does it invokes the SMO scripting capabilities to script out an entire database. You can do the same: instantiate a Scripter object instance, then add to it the objects you want scripted, then extract the T-SQL generated script. That is exactly what 'Generate Scripts' in SSMS does. There is an example in MSDN for scripting:
//Connect to the local, default instance of SQL Server.
Server srv = new Server();
//Reference the AdventureWorks2008R2 database.
Database db = srv.Databases["AdventureWorks2008R2"];
//Define a Scripter object and set the required scripting options.
Scripter scrp = new Scripter(srv);
scrp.Options.ScriptDrops = false;
scrp.Options.WithDependencies = true;
//Iterate through the tables in database and script each one. Display the script.
//Note that the StringCollection type needs the System.Collections.Specialized namespace to be included.
Microsoft.SqlServer.Management.Sdk.Sfc.Urn[] smoObjects = new Microsoft.SqlServer.Management.Sdk.Sfc.Urn[1] ;
foreach (Table tb in db.Tables) {
smoObjects[0] = tb.Urn;
if (tb.IsSystemObject == false) {
System.Collections.Specialized.StringCollection sc;
sc = scrp.Script(smoObjects);
foreach ( string st in sc) {
Console.WriteLine(st);
}
}
}

Answer 2

Import from one DB in the other

Answer 3

Scripting the database objects out and then running them on the older instance is the way to go. If you have SQL 2008-specific features coded, you'll find it right off when you run the script on 2005 (so test before you try it on Production!).
Setting Compatibility Mode will not help here. If I have a (2008) declared table type and I use it with stored procedure parameters, there's nothing SQL or anyone else can do to migrate it to 2005. Using "modern" systems to support legacy systems is ugly at best.
Just 'cause I'm doing it again, my preferred migration path is:
Have development, "staging", and production environments, all at 2005
Upgrade staging to 2008
Continue developing on dev/2005, and push changes to staging (2008) and production (2005). When it works on 2008 (and it almost certainly will), mgmt will be content with upgrading production. And your 2005 builds will still work on 2005 production.
Upgrade production. Hey, it worked on staging, so it's safe and sane
And everything generated from (2005) development works on (2008) staging and production
And only then do you upgrade development and get to play with your new toys