There’s a debate over on Scott Hanselman’s blog about the GUI v CLI in the comments for his Azure CLI post. It’s a blend of people complaining about one or the other, mixed with a few (I think) rational people that recognize the GUI and CLI are both valuable. In fact, there’s one person that mentions SQL Server and the SSMS GUI that can generate scripts for later use.
I like the command line, but sometimes it’s hard. I don’t remember the syntax for a variety of commands, especially PowerShell where I use tab completion constantly. I don’t even remember options for many T-SQL functions, because I don’t use them very often. I may find myself depending on Google or BOL for a quick refresher, but often I’ll just use use SSMS if I can to pick some items in the GUI, click Script, and then examine the code before executing it.
I really don’t mind someone wanting to use the GUI the vast majority of the time they’re working, but someone should be comfortable with a CLI interface. If there is a task that need repeating multiple times, then I really want everyone using the CLI. It doesn’t matter how you’ve written the code, executing something from a CLI is much more reliable than having to click around a GUI, trying to be consistent and quick, over and over. The CLI just works better.
I’d like to think that most computer professionals these days are able to use a CLI, even if they aren’t too comfortable. The growth of PoSh as a wrapper around so many features and functions in the MS stack certainly contributes to this, as well as fact we seee so much code as code, not as images from a GUI. Github and collaboration, as well as lots of code samples in articles should mean that many people are comfortable working with code and executing it from some CLI.
I’m sure there are plenty of exceptions. Someone that works mostly with SQL Server might be happy running code in a query window and use SSMS for everything else. They might not even be aware that they can build things like SQL Agent Jobs from a CLI. I get it, the GUI is quick and easy. I use it for jobs, for Extended Events, and various other tasks where the code is complex and cumbersome. However, if something is easier from a command line, I like using it. Perhaps that’s why my console of choice, ConEmu, is always just a CTRL+~ away.
Steve Jones
The Voice of the DBA Podcast
Listen to the MP3 Audio ( 3.7MB) podcast or subscribe to the feed at iTunes and Libsyn.


Probably like many others, I invest in SQL code if there is a chance I will need it again in the future. I end up having hundreds of scripts if I spend long time in one environment. I pay attention to my script naming standards, but am open to other file organization tips.
How about when to use TSQL or PowerShell?
Otherwise, SSMS all the way.
LikeLike
Thanks for the response, and that’s about what I’d expect. Lots of scripts for different items. Out of curiosity, what naming standard do you use? Do you back these up or share them on something like DropBox or Github with your team?
LikeLike
Before saving SQL code I go through the following steps;
1) DBA specific or App specific:
App: Use a folder being backed up regularly on server
Folder name = App/DB/Server/Client name
DBA: Use another folder for Admin/Oper/Monitoring scripts
FORMAT:
[ActionName]_[ObjectName]_V[VersionNumber]_[Importance].sql
2) [ActionName]:
For single/simpler commands, use command name (like SELECT)
For multi-command/complex/process/batch, use synonyms (like GET)
SELECT vs GET, INSERT vs ADD, UPDATE vs MOD, DELETE vs REM, CREATE vs BUILD
For Agent Jobs, JOB
3) [ObjectName/ProcessName]:
Use hyphen (-) to delimit multiple words
4) V[VersionNumber]: ##-##
Double digits for both major and minor version number separated by (-)
[Date]:
Alternative to versioning, YYYYMMDD format can be used
5) [Importance]:
A special character can be used like star rating system. I use (+); one to five scale.
Alternative to special characters, ALL_UPPERCASE charters can be use to state importance.
6) For a group of scripts in order, e.g. deployment script, two digit prefix may be used.
00_Readme.sql
10_xxx.sql
20_xxx.sql
EXAMPLES:
select_new-cust-id_v01.sql
get_daily-deltas_20170315.sql
sync_cust-details_v02-03.sql
job_daily-account-refresh_20170315.sql
build_monthly-report_V07-02_+++.sql
LOOP_USER-DBS-WHILE_V02_++.sql
…
LikeLike