Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
eyechart
Master Smack Fu Yak Hacker
3575 Posts |
 Posted - 2005-02-07 : 17:11:39
|
| Does anyone know of a method to help automate the deployment of code (sprocs, functions, UDFs or whatever) to multiple SQL Server instances?Basically, I have many administrative scripts and jobs that I need to push out to a bunch of different SQL instances and I hate doing it manually. Are there any tools that I could use to make these less painful then it currently is?I have just started to code something up myself, but I don't want to reinvent the wheel if I don't have to.thx.-ec |
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2005-02-07 : 17:15:58
|
| I use osql.exe for this type of thing.osql -SServer1 -E -iC:\scripts\SomeScript.sqlosql -SServer2 -E -iC:\scripts\SomeScript.sqlAnd to be slick with this, use Rob's approach:http://weblogs.sqlteam.com/robv/articles/4099.aspxTara |
 |
|
|
eyechart
Master Smack Fu Yak Hacker
3575 Posts |
Posted - 2005-02-07 : 18:00:49
|
| Brilliant!thx -ec |
|
|
|
Kristen
Test
22859 Posts |
Posted - 2005-02-10 : 01:50:30
|
| I concatenate all my individual SQL files (for SProcs & Triggers) together and execute that as one file.I have a BATCH file (a.k.a. String&ChewingGum) that does this - it locates all files since the last "update script", and concatenates them - adding PRINT statements so when there is an error I know which original file caused the problem.It then creates a ___yyyymmdd___.___ file as a marker for when the last Update Script was created.Only slight problem with this is that the execution order may have dependencies, so if I see a sysdepends error I rerun the script again (not that sysdepends is any darned use whatsoever)For DDL I script every database change into sequentially numbered files, and run those on all target databases.All my SQL files have a call to an SProc that logs their execution, and version number. So for a given database I can discover what the current version of any SProc script is; and also what the most recent DDL script was that was run - and thus run from that point onwards at the next "rollout"Kristen |
|
|
|
|
|
|
deploy code to multiple SQL instances in one shot