Keith,

Coincidentally, I just received a free book yesterday on "Programming SQL Server 2005". I'm sure it probably gets into some of this stuff that you just mentioned (writing tools for example). It's a pretty fat book ... more than 850 pages. Now, to just get some time to read it all! <g>

Thanks for your input! =)

~~Bonnie




>>>You gotta do it the MS way or they get real touchy (sadistic). They want you to be super organized (so their lawyers can easily find evidence) and put all of your .sql files into a solution (black hole). The solution has at least one pre-defined connection that each file is linked to and is automatically opened when the file is opened.
>>
>>Keith,
>>
>>Hmmmm ... there's probably some logic to that hidden somewhere. <g> But what if I don't wanna do it their way?!? I'm too darn stubborn!! <g> It's just not the way I'm currently used to doing my SQL work, but I suppose that when I get some free time, I'll look into what benefits (if any) there are to creating a solution. Have you done this yet?
>>
>>~~Bonnie
>
>I use solutions a lot when I am working solely on the database as a DBA or SQL Developer. It's quite nice once you get into it. The things I like best about it is source control integration and its custom tool interface. It works like the VS.NET Database project was supposed to work. You can add any type of file to the solution (like word and visio docs).
>
>The coolest thing is writing a tool. There is a set of about 10 pre-defined parameters that can be sent to a console app - like current highlighted text, selected filename, selected project name, selected database object, solution filename, etc... Any console output goes to the output pane in SSMS.
>
>In the console app, you can do stuff like create a new script file by combining a template with the highlighted database object. Then add the new script file to the solution (it's a serialized object).
>
>A really cool one is to generate a complete migration script for the solution with a single click. I did this a while back. I had to add some flags (key-values in the header comment block) to the templates to control how the script was packaged in the migration script, but it worked really well and saved hours of monotonous and error-prone work.
>
>The hardest part was reverse-engineering the solution object so I could serialize and de-serialize the file.