It seems like the generation of SQL scripts from the SQL Server Management Studio is terribly slow. I think that the old Enterprise Manager could run laps around the newer script generation tool. I've seen a few posts here and there with other folks complaining about the speed, but I haven't seen much offered in the way of alternatives.

Is there a low-cost/free tool for scripting an entire SQL Server 2005 database that will perform better that SSMS? It would be hard to do worse.


I don't know what is "terribly slow" for you, but I have a decent performance with SQL 2005 Management Studio. In either case, RedGate products are very cool. Unfortunately it's not free.

Martín Marconcini

What kind of scrpt generation are you talking about now?, generating create scripts from the objects in the database is way faster in SSMS compared to EM. But if you are running an select or something that gives you lots of rows in the grid, it is crazy slow.. like scripts generating inserts statements of all rows in an table, if you got lots of data, it is almost not doable.

+3  A: 

We are using the tools by RedGate which I personally find very useful in any aspect of work with databases. For scripting I would recommend the SQL Compare (you need a pro version for scripting). The SQL Compare is a must have for deploying schema changes from the deployment DB to the live Server and a real timesaver.

Those tools are not free but I think they could save you money in a long run

+3  A: 

See the Database Publishing Wizard which is part of the SQL Server Hosting Toolkit which generates a single SQL file for both schema and data.

Duncan Smart

@neslekiM/Martin - I'm just right clicking on a database from SSMS and going to Tasks->Generate Scripts. Then selecting script all objects. To create a script from a database with about 700 objects, it's taking about an hour. I use the scripts to refresh our dev server now and then. I don't want to bring the data over because some of the tables are quite large. I just want to recreate the stored procs, tables, etc...

Paul G