views:

47

answers:

2

I'm using SQL 2005. I can right click on a database and create scripts for the database that will recreate the structure (tables, views, stored procedures) elsewhere. Or just as a backup, version, etc.

But, is there a way I can schedule it to do this? And output to a folder I choose?

I really appreciate the help.

Don

+2  A: 

You could schedule this using SMO probably, though it may take some work to get up and running.

However, a more elegant approach might be to schedule a full backup to a new file (with today's timestamp), and archive it. This way retrieving the scripts is as simple as restoring that version of the database somewhere, and extracting manually.

An even better approach: if you store your change scripts in source control, you should always be able to pull any version of the database.

Aaron Bertrand
Thanks Aaron. I'm still not really sure what to do though. I'd like to have a backup that I can view the contents of without having to restore the full database backup file.Just to share the level I'm at, I didn't even know what SMO was until you typed it and I looked it up. ;-)I guess I'm just looking for the simplest solution.
DonnMt
If you have a server with sufficient disk space, you can certainly automate the backup and restore so that there is no manual work involved. For example, you could do a full backup every night, and by default restore that to another server (again, on a schedule, not manually) every Saturday, with a database name that includes the date. If space is an issue (and eventually it will be) you could also automate dropping the oldest database on file as part of the same job. And you could restore any interim DB manually. Looking at a database is much easier than looking at a bunch of scripts, IMHO.
Aaron Bertrand
A: 

I've used both SMO's predecessor (SQL-DMO) from VB as well as ApexSQLScript from the command line to do scheduled scripting of objects.

This is fine for very large databases where you do not have ability to quickly restore a database just to look at schema versioning information for small tables/views/procs which happen to live in the same database.

In fact, this is a good argument for separating out small fast-changing schemas into separate databases from large-slowly changing schemas.

Cade Roux