Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.
One of the really basic things I think everyone should understand is how to get scripts from Management Studio (SSMS) and saving them. In fact, I’ve written that everyone should use this button and really not ever execute their GUI changes. Capture the script, save that, and automate things.
However, that’s not what this post is about. This post is about how you get a script to look at changes, or better understand how SSMS might implement your changes.
Editing a Table
Let’s say that you want to redesign a table, so you Edit it in the SSMS Table Designer. Here, you can see I have small table with a few fields.
I want to rename the field with incorrect casing as well as insert an OrderDate column in the middle. I have made those changes below.
Now, I’m not sure how these changes will be made in SSMS, and I certainly want to be careful in production. We want a script we can examine and approve.
Certainly, I could use something like SQL Compare to generate a script between two databases. That would include transactions and error handling and more. That’s my preferred method. However, since not everyone has SQL Compare (a mistake! 
), let’s just use SSMS.
Instead of saving, I’ll click this button.
Or I’ll go to this menu item.
Once I do that, after a warning, I get a script dialog.
I can now save the script and then open it back up in SSMS. I can see all the changes that the scripting engine thinks we should make.
This allows me to learn about one way to make these changes, as well as see things that might concern me, such as poorly named constraints and indexes.
SQLNewBlogger
This is a great productivity and learning technique, but also a core thing I’d hope most DBAs knew. You could certainly write about how you use this, or how this might have been helpful in a situation. Showcase your knowledge on this topic with the #SQLNewBlogger hashtag.
Voice of the DBA 