A community of more than 1,600,000 database professionals and growing

I was watching the San Diego Technology Immersion Group meeting in September, and found myself transported back into the past. This month was the first meeting of the Linux chapter, spending a few months working through The Linux Command Line.

Watching from home, I watched the hosts walking through the command line in Linux, showcasing various basic file comments. Seeing them explain and execute commands like ls, rm, alias, cat, tail, less, and other commands in a text session reminded me of learning Unix at university on SunOS. Slowly various bits of knowledge came back to me from my own experiments learning how to work with files, full of text data, interspaced with my regular visits to the "man" pages when something didn't work. In fact, seeing the man pages come up on the YouTube session made me smile.

It's funny to think how much the world has changed. Even now, I have an Ubuntu VM that I run at times, but it's mostly a GUI shell, and my interactions with the command line are fairly minimal. That's completely the opposite of my time at university and my first job where I pretty much lived in the command line. My code editors were vi and emacs that I ran across a dozen X Windows sessions open on various machines in the college computer lab. My interactions were really working with text and text commands. Even now, I might use SSMS and Visual Studio, but I'll pop into a command line to check my git repo or spend time playing with PowerShell and executing commands in text sessions. While working with Python I'm as likely to use the REPL from a command window as I am to use an editor like VS or PyCharm. I really just like the interaction of the command line.

Not everyone feels that way, and that's fine. I agree that GUI based systems are more convenient at times. In fact, I often use various GUI items in SSMS build up a task, such as an Extended Events session, and then script the result to give me code that I can execute. GUIs do some things extremely well, but allowing for repeatability is not one of them. They can also easily hide the actual commands and defaults being executed.

I think everyone working in technology needs to have some skill in working with a command line. Even if you want to use T-SQL to script all your tasks, you should be familiar enough with something like SQLCMD to execute a script in case you run into a situation where SSMS might not work. This might be especially true as you learn to automate more of the work your systems require and perhaps execute these scripts through other tools, like an Enterprise scheduler.

If nothing else, the command line teaches you how to work in a methodical, step by step process. However, I'd argue it develops new skills that might lead you to do solve a problem in more creative ways. Perhaps you'll even grow to use a command line language like PowerShell to accomplish some repeatable task. You might find it works better than the old way you used to work.

Join the debate, and respond to today's editorial on the forums

The Table Value Constructor has a few rules, one of which is that a subquery cannot contain multiple columns. Each row value constructor would need multiple subqueries to fill out the row. 

Query 1 has scalar values and works fine.

Query 2 uses a subquery with one column returned for the second vlaue, and this works fine.

Query 3 has multiple columns returns and fails.

Query 4 has multiple columns returns and fails.

Query 5 returns a scalar value for each column, and that is a valid statement.

Ref: Table Value Constructor - https://msdn.microsoft.com/en-us/library/dd776382.aspx

» Discuss this question and answer on the forums