What Brann is mentioning from the Visual Studio 2008 SP1 Team Suite is version 1.4 of the Database Publishing Wizard. Wrapping each string in an 'exec' statement would work better if using SqlCommand to run the script. It seems each string is a sensible batch, and putting GO after it makes it work in tools like SSMS. StringBuilder builder = new StringBuilder() check if the procedure is not a system object Display the script.įoreach (StoredProcedure sp in db.StoredProcedures) Iterate through the stored procedures in database and script each one. check if the view is not a system object Iterate through the views in database and script each one. check if the table is not a system table Iterate through the tables in database and script each one Scrp.PrefetchObjects = true // some sources suggest this may speed things up = true // to include referential constraints in the script Connect to the local, default instance of SQL Server.ĭatabase db = srv.Databases This code, modified from the example, works for me (though I daresay you could tidy it up and comment it a bit more): using I found it is neccessary to collect all the URNs and hand them to the scripter as an array. However if you want everything to script correctly with a 'full' schema that includes 'DRI' (Declarative Referential Integrity) objects like foreign keys then scripting tables individually doesn't work the dependencies out correctly. (I would hope MS didn't write it twice!) There are several examples on MSDN like this one that show scripting tables as individual objects. By contrast the options available with SMO almost exactly match those in SSMS, suggesting it is probably even the same code. SqlPubwiz has very limited options compared to the script generation in SSMS.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |