Author: way0utwest

  • Basic SQLCMD–#SQLNewBlogger

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    I had the need to connect from the command line recently, and decided to make a quick post on using SQLCMD, as I had an issue.

    SQLCMD is a command line utility that comes with SQL Server. I know many people don’t use command lines, but they are handy at times. I recently opened a command prompt.

    2016-04-06 12_47_33-Photos

    I then typed SQLCMD. After a delay, I got this:

    2016-04-06 12_51_23-Photos

    The issue here is that I don’t have a default instance on this machine. All of mine are named. I need to provide a –S parameter, with a server name (and possibly instance name).

    2016-04-06 13_01_33-Photos

    I do that and I’m connected. By default, SQLCMD (and osql) try to use Windows Auth. The 1> indicates that the utility is ready for T-SQL queries. You need to know your language here as there’s no help.

    I can enter code, and check my user name. I do this, and get a 2>. The end of a batch is indicated with “GO” and this will execute the batch. You can see how this works below:

    2016-04-06 13_01_47-Photos

    I can use this to make my code easier to read. I can format code as I would in an editor, though be aware you can’t go back and edit previous lines.

    2016-04-06 13_07_03-Photos

    If I enter go, I’ll get this:

    2016-04-06 13_07_15-Photos

    Not so easy to read. I have to scroll up to even figure out what the display is:

    2016-04-06 13_07_26-Photos

    As you can see, using SELECT *, or retrieving too many columns make results hard to read. You would to wise to pick only those columns you need to return.

    To leave SQLCMD, you can type exit, which will return you to the command prompt.

    2016-04-06 14_00_07-Start

    This is a short look at SQLCMD. The older, osql, utility functions the same way, and both are good, lightweight ways to connect to your SQL Server instance.

  • Successful Projects

    What techniques or ideas allow you to build a successful software project? There’s been no shortage of writing and studying on this topic across the last few decades. So many people expend energy and thought trying to solve the problems of building software at a high level of quality, in a reasonable timeframe, and within some scope that matches the desires of their customers.
    I’d like to think most of us succeed, but study after study shows that most parties are disappointed in some way. Developers are under pressure and can’t/don’t built the level of quality they’d like. Management sees software as taking too long and costing too much. End users see too many bugs, though I think that overall quality has risen in the last decade are more proven frameworks are used and developers have gained more experience in newer and better development techniques.
    I ran across a post on a test for successful software projects. It’s the Kevin Test for Successful Projects, and it’s based on a combination of the Joel Test and the Rands Test. The idea is not that you implement all of these test items, or do them perfectly, but that you work towards doing more of them than not. There are explanations of what each item in the test means in the various pieces.
    I think these are good guidelines for projects, and they’re simple ones. They certainly can apply to database development. However most people don’t really want to spend time on these tasks. However, I think the mundane nature of these items slows you slightly, but forces you to think more about what you’re doing. The gains in quality and velocity, in my mind, come from avoiding rework, avoiding losing work, and avoiding regressions.
    Sometimes I think the problems in software development aren’t that we write poor code, but rather that we rush a complex endeavor, being willing to redo work rather than proceeding in a more engineered fashion.
    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.8MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • SQL Saturday #492–Phoenix

    It’s almost time for SQL Saturday #492 this weekend in Phoenix. I haven’t been there in a few years, but I’m heading back for a quick trip to the desert.

    I’ve got two sessions scheduled this weekend, and if you’re attending, I’ve love to see you at one of my sessions:

    The event has grown quite a bit, with 13 tracks. I’m hoping a lot of people in the Phoenix area are coming out for a free, exciting SQL Server conference.

  • Build a POC

    I have a few friends that work sales engineers for various companies. They often build a proof of concept (POC) project for various customers or potential customers, which is a great job. They get to showcase how a particular product or technology might work in a situation. We see this all time from lots of companies, including a great POC from BMW shown at the recent //build/ conference.

    Sometimes the POC is more mockup than reality, but often this is a way to actually test some software and determine if you should invest more resources in that particular direction. I’ve used this myself, setting up a small project to test items, and I recommend this for others that might want to try something out.

    For example, I like the idea of Continuous Integration (CI) for databases, but implementing CI in one of your production pipelines, on a production database is hard. It’s complex, and it can be distracting, not to mention stressful. Who wants to make a deployment mistake in production?

    What I recommend instead is that you take a small database and practice. I don’t like Adventureworks, but you could grab a few tables from your system and build a new database, download a pre-built one from SQLskills, or even just create a Hello World type database with one table. Download TeamCity, or use the Visual Studio Online build system. Experiment and learn how to take your database code and programatically deploy changes to another system. Redgate has toolsto help, or you can roll your own.

    No matter how you do it, try using a POC the next time you are wondering what the best way to proceed with new technology. You might find the POC makes a new technique more approachable and gives you confidence to tackle deploying the changes in the rapidly changing environments in which we work.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.6MB) podcast or subscribe to the feed at iTunes and LibSyn.