March 20, 2008 at 12:01 am
Comments posted to this topic are about the item Applying Your Scripts across Multiple SQL Server Databases
My Blog:
March 20, 2008 at 3:12 am
I am responsible for 16 databases on a single server - each database is the same 'shape' (ie. tables/views/stored procedures) etc., but contains data from disparate sources. When applying database changes I had a tick list to make sure the same changes were applied to each database, and in some cases there were multiple scripts to be applied. I'd sit in front of Management Studio waiting for a script to complete (which, when data changes were being made, could take some time over millions of rows). Then I'd move on to the next database.
Then I bought Multi Script which now manages the whole lot for me. I've binned my tick lists.
March 20, 2008 at 3:29 am
The tool seems cool. But I should not comment on these in positive or negative unless and until using it. As the tool is new we will know the advantages and disadvantages of it when it will be extensively used in production.
Thanks to the author for explaining it well. 🙂
Regards
March 20, 2008 at 3:35 am
I concur with Anirban. We have to use it a lot more in production to identify any pitfalls. However, I am using the product in my production environments and so far it does what it says on the tin.
September 11, 2008 at 1:08 am
I personally prefer QueryBlaster (www.QueryBlaster.com). I have been using it on my production servers for a few months now and I love it. No more skipped over databases and I'm finished in a fraction of the time! 😎
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply