Docker And SQL Server

July 29, 2018

Containers are a way to virtualize a single application, as opposed to virtualizing an entire server. We can run an application in this container without installing the product or worrying about all of the dependencies of that application. Everything needed to run an application is in the container.

Docker is the most popular platform for running and managing containers.

Prerequsites for Installing Docker:
To install Docker on Windows, we’ll need to have Microsoft Windows 10 Professional or Enterprise 64-bit(You can also run on Windows Server), we need a version that will support virtualization. We also need virtualization enabled on the machine (You’ll need to go into the BIOS to enable this).
We’ll need Hyper-V and Containers features enabled as well. We can do this in the Control Panel, or use Cortanta to search for ‘Turn Windows features on and off’. Make sure the Containers and the Hyper-V items are checked. The Docker installation will check to see if these features are enabled, and will give you the option to enable these features then, but setting these before hand will save you a reboot.
Notes that if Hyper-V is enabled, then Virtual Box will not work, if you have that installed.

Installing Docker:
The Docker Community Edition for Windows is a free download, but you’ll need to set up a Docker login.
The install is pretty straight forward. For my example, I checked to Use Windows containers instead of Linux containers.

Basic Docker Commands:
We can use the Command Prompt or the Powershell Window to run Docker command, I used Powershell for these examples.

docker --version

: This will return the version and build number for the Docker install.

docker --help

: This will give us a list of available Docker commands. We can also use this to get additional information on a specific command, for example if we wanted more information on the version command, we would run docker version –help.

Sample Docker Container:
We can run a sample Hello World container just to make sure everything is set up on running correctly. We can run the command:

docker run hello-world

This will pull down the Hello World image and run it. If everything is running correctly, you’ll see a message ‘Hello From Docker!’. If things aren’t set up correctly you’ll see an error message.
Initially I got an error:
“container xxx encountered an error during CreateContainer: failure in a Windows system call: No hypervisor is present on this system.”
I had let the Docker install enable the Containers and Hyper-V components for me. When I went to check on the options, The Hyper-V Platform option under Hyper-V was greyed out with the message “Hyper-v cannot be installed: Virtualization support is disabled in the firmware”. It turned out that Virtualization was turned off on my laptop, which prevented this option from being enabled. I didn’t get an error during the install when it trying to enable these features, and it took me a while to figure out the issues. So I would recommend running through the prereqs yourself, instead of relying on the install to do this.

Other Docker Commands:

docker images

: List all of the installed images.

docker rmi hello-world -f

: To remove an image (hello-world). The -f flag will force removal.

docker container ls

: List running containers

Running SQL Server:
Now to a more practical use. We can run SQL Server in Docker. A container for SQL Server Developer edition is available through Docker Hub . We can view some information on the container here.
We can run this command to download the container:

docker pull microsoft/mssql-server-windows-developer

The download is 4-5 gigs.
Once we have pulled the container down, we can start it up:

docker run -d -p 1433:1433 -e sa_password=WeakPW12 -e ACCEPT_EULA=Y microsoft/mssql-server-windows-developer

It will take a few seconds to start up. Once the container is running, we’ll see an ID printed to the console. Make a note of this ID.
So there are a few parameters that have been set in the run command. -d means detached, which means that the container runs in the background. -p (for publish) designates the port for the service, we’ll stick with the SQL Server default of port 1433. We list two ports, one for the container and another for the host. -e will set an environment variable, in this case we’ll indicate that we accept the user agreement. We’re also using -e to set the sa password for this session. At first, I set a very simple sa password, and then I had issues trying to connect to SQL Server. When creating the sa password, you’ll have to follow the complexity requirements for a sa password, you won’t get an error message for an invalid password. The sa password has a 8 character minimum, plus you’ll need at least 3 from upper case letters, lower case letters, numbers and special characters.
We can connect to our SQL Server container either with the SQLCMD command line tool, or with SSMS. For this example, we’ll use SSMS.
To connect with SSMS, we’ll need to get the IP address for our running SQL Server. Using the ID we got when starting the container, we’ll run this command:

docker inspect {ID}

You can also use the 12 character Container ID. We can get that ID by running:

docker ps

In the output, we’ll go to Network Settings / Network / IP Address , and make a note of this address.
To connect with SSMS, we’ll use the IP Address as the Server Name (include a comma then the port number if not using the default port). Select SQL Server Authentication, then use sa and the sa password we passed in when starting the container.
Once we’ve connected, we can use SSMS to create objects, or open a query window, just as we would with any SQL Server.

Once we’ve completed, we can stop the container passing in the Container ID for {ID}:

docker stop {ID}

Once we stop the container, we’ll lose whatever objects and data that we’ve set up. It is possible to map the container to use data and log files on the host machine, this page goes through the setup for that.

Get started with Docker
Windows Containers
Docker Documentation
SQL Server 2016 Express Edition in Windows containers


Incorrect syntax was encountered while parsing GO

June 30, 2018

I have a Powershell script I created to script out the views and stored procedures in a database. Usually I just use it to find all the references to a particular table or column, but in this case I wanted to run the procedure on another database. When running the script, I ran into this error:
“A fatal scripting error occurred.
Incorrect syntax was encountered while parsing GO.”

The error came from the SQL in this script. (The issue is dependent on formatting, I couldn’t get the format to come through in the WordPress page).

At first I was puzzled, everything looked fine to me. I did have the extra space in the front of the third line, so I deleted it and re-ran. Still with the same error. I knew that GO needed to be on its own line (unless I added a number to indicate I wanted the batch to run that many times).
I came across this post that described the same error. I didn’t have anything on the same line as the GO, but I decided to check my Powershell script. Instead if using a carriage return and line feed after the GO:

I had inadvertently used a `v (a vertical tab) instead of a `n. Error on my part, but easily corrected.
Instead of regenerating my script, I could also save a copy of the script from SSMS.
In the Save dialog, select the arrow next to the Save button and select Save With Encoding.
Under Line Endings, change ‘Current Setting’ to ‘Windows (CR LF)’, then click OK and then Save.

Running Totals

May 28, 2018

Displaying a running total in SQL Server is very straightforward, thanks to window functions and the OVER clause.
We’ll set up an example with some records for a payment amount over several days.

drop table if exists #Test;

create table #Test (
PaymentDate date not null primary key,
Amount int not null

insert into #Test(PaymentDate, Amount) 
values ('2018-05-29', 25), ('2018-05-30',10), ('2018-05-31',20), 
	('2018-06-01',30), ('2018-06-02',40), ('2018-06-03', 15);

select * from #Test;

Adding a running total is just a matter of SUM with an OVER clause.

select PaymentDate, Amount,
	sum(Amount) over (order by PaymentDate) as RunningTotal
from #Test
order by PaymentDate;

The RunningTotal column will show the total of all payments made on that day and any earlier date.

We can also use PARTITION to display a running total for just that month as well.

select PaymentDate, Amount, datename(month, PaymentDate) as MonthName,
	sum(Amount) over (partition by month(PaymentDate) order by PaymentDate) as MonthRunningTotal
from #Test
order by PaymentDate;

In the first example we used default settings for the OVER clause, which is for the current row plus all rows before it. Here is the first query with the default explicitly given.

select PaymentDate, Amount,
	sum(Amount) over (order by PaymentDate rows unbounded preceding) as RunningTotal
from #Test
order by PaymentDate;

We can change this setting to return other combinations. In the final example, we’ll return the running total as the payment amount for the current row plus the amount from the day before.

select PaymentDate, Amount,
	sum(Amount) over (order by PaymentDate rows 1 preceding) as RunningTotal
from #Test
order by PaymentDate;

Window Functions


April 22, 2018

When assigning values to a variable, we can use SET or SELECT. SET is the ANSI standard method. If we have a set value we want to assign to a variable, either method works just as well as the other. When we are retrieving values from a table or view, then there are some differences in behavior.
In order to run through some examples, we’ll set up a temp table with 1 column and 2 rows of data.

drop table if exists #Test;
create table #Test (RecordId int not null primary key);
insert into #Test(RecordId) values (1), (2);

When selecting by the primary key, we know we’ll get one value, so things are straightforward.

declare @VarSelect int;
declare @VarSet int;

select @VarSelect = RecordId from #Test where RecordId = 1;
set @VarSet = (select RecordId from #Test where RecordId = 1);

select @VarSelect as VarSelect, @VarSet as VarSet;

Let’s try an example of retrieving a value that doesn’t exist in the table. We’ll set 0 as the default value for the variables.

declare @VarSelect int = 0;
declare @VarSet int = 0;

select @VarSelect = RecordId from #Test where RecordId = 3;
set @VarSet = (select RecordId from #Test where RecordId = 3);

select @VarSelect as VarSelect, @VarSet as VarSet;

Using the SET method will return NULL, where the SELECT will leave the default value in place. If we’re using the variable one time, this behavior may not cause issues, but reusing the variable could cause confusion.
In the following example, the first select will return 1. The second select won’t find a value, so it will also return 1.

declare @VarSelect int = 0;

select @VarSelect = RecordId from #Test where RecordId = 1;
select @VarSelect as VarSelect;

select @VarSelect = RecordId from #Test where RecordId = 3;
select @VarSelect as VarSelect;

When returning multiple values, a SET will raise this error:
“Msg 512, Level 16, State 1, Line x
Subquery returned more than 1 value. This is not permitted when the subquery follows =, !=, <, , >= or when the subquery is used as an expression.”
The SELECT will return one of the values from the result set.

declare @VarSelect2 int = 0;
declare @VarSet2 int = 0;

select @VarSelect2 = RecordId from #Test;
set @VarSet2 = (select RecordId from #Test);

select @VarSelect2 as VarSelect, @VarSet2 as VarSet;

In this case, I would rather an error be thrown that to just return one of the result set values.
Overall, it seems like SET it the better choice. We’ll get an error if multiple values are returned, and if no value is returned then we’ll get a NULL.

Converting Float Values To Strings

March 26, 2018

A coworker and I were looking at a request where we needed to write float values to a file, but have the values be of a uniform length (In this case, the float column was storing a monetary value, which isn’t a good idea, but that’s what we had to work with). In this case, all values were out to 4 decimal places, so it was a matter of padding the value to the left of the decimal to get everything to an equal length. The first thought was to convert the value to a string, pad the from with zeros, and from that take a string of the specified length.
To my surprise, it turns out that casting a float to a string data type (a varchar in this case) ends up rounding the value in some cases, and converting to scientific notation in others. With a little Googling we found out that using the STR function is the recommended way to make this conversion. STR takes has length and decimal value parameters to control how many digits are output.
I had used the FORMAT function for dates before, but it also handles numbers as well. This turned out to be the approach that was used, since in the FORMAT function we can specify padding to a certain length.
Here’s SQL for some test data long with the different approaches.

create table dbo.FloatTest(
FloatValue float not null

insert into dbo.FloatTest values (123.45678);
insert into dbo.FloatTest values (2.66993256);
insert into dbo.FloatTest values (0.00001);
insert into dbo.FloatTest values (55555.84);
insert into dbo.FloatTest values (321.0987654);

select  FloatValue as OriginalValue, 
        cast(FloatValue as varchar(15)) as CastValue,
	str(FloatValue, 20, 10) as StrValue, 
	format(FloatValue, 'F9') as FormatValue,
	format(FloatValue, '0000000000.##########') as CustomFormatValue
from dbo.FloatTest;


With FORMAT, we can specify a standard format for floats with F, followed by the number of decimal digits. Or we can create a custom format. Using a 0 for a required digit and a # for an optional digit allows us greater control over what is returned.

SQL Server And JSON

February 11, 2018

SQL Server 2016 added support for working with JSON. Although there isn’t a JSON datatype, there is still the ability to output query results to JSON, and to break down JSON into rows and columns.
This post will run through some basic examples of working with JSON. I’m using SQL Server 2017 although 2016 can be used as well.

First I’ll create some test data.

drop table if exists dbo.JsonTest;

create table dbo.JsonTest(
FirstName varchar(20) null,
LastName varchar(20) not null,
StatusCode varchar(10) not null
insert into dbo.JsonTest(FirstName, LastName, StatusCode) values ('Mike', 'Smith', 'Inactive');
insert into dbo.JsonTest(FirstName, LastName, StatusCode) values ('Jane', 'Doe', 'Active');
insert into dbo.JsonTest(FirstName, LastName, StatusCode) values (NULL, 'Jones', 'Pending');

Next is returning relational data as JSON. Much like the FOR XML clause returns XML, the FOR JSON clause returns the selected data in a JSON string. AUTO will return a default structure, where using PATH will allow more control on the output, like naming the root node and returning NULL values instead of omitting them.

select FirstName, LastName, StatusCode FROM dbo.JsonTest FOR JSON AUTO;
select FirstName, LastName, StatusCode, 'Atlanta' as [Address.City], 'GA' as [Address.State] FROM dbo.JsonTest FOR JSON PATH, ROOT('People');

The second select also shows how to nest data, in this case in an Address node.

OPENJSON will return one row for each node in a JSON string.

declare @JSON as varchar(4000) = '[{"FirstName":"Mike","LastName":"Smith","StatusCode":"Inactive"},{"FirstName":"Jane","LastName":"Doe","StatusCode":"Active"},{"LastName":"Jones","StatusCode":"Pending"}]';


With OPENJSON, we can also parse JSON into relational rows and columns, provided that the column name matches the JSON attribute name. If the names don’t match then NULLs are returned.

declare @JSON as varchar(4000) = '[{"FirstName":"Mike","LastName":"Smith","StatusCode":"Inactive"},{"FirstName":"Jane","LastName":"Doe","StatusCode":"Active"},{"LastName":"Jones","StatusCode":"Pending"}]';

FirstName varchar(20),
LastName varchar(20),
StatusCode varchar(10)

It is also possible to map a JSON attribute name to a different name for the output, we’ll need to specify which value to match to.

declare @JSON as varchar(4000) = '[{"FirstName":"Mike","LastName":"Smith","StatusCode":"Inactive"},{"FirstName":"Jane","LastName":"Doe","StatusCode":"Active"},{"LastName":"Jones","StatusCode":"Pending"}]';

GivenName varchar(20) '$.FirstName',
Surname varchar(20) '$.LastName',
StatusCode varchar(10)

There are also a few JSON Functions available.
ISJSON will determine if a string is valid JSON or not.
JSON_VALUE will extract a scalar value.
JSON_QUERY will return a JSON fragment or an array of values.
By default, the JSON functions are in Lax mode, which means that an error won’t be raised with an invalid operation, a NULL values will be returned instead. Strict mode can be specified, in which case an error will be raised with an invalid operation.

declare @JSON as varchar(4000) = '[{"FirstName":"Mike","LastName":"Smith","StatusCode":"Inactive", "Language":["English","Spanish"]},{"FirstName":"Jane","LastName":"Doe","StatusCode":"Active"}]';
declare @NotJson as varchar(4000) = 'Not a JSON string';

-- Return bit to determine if a string is valid JSON or not

-- Get scalar value - 0 based array
SELECT JSON_VALUE(@JSON, '$[1].FirstName');

-- Return JSON fragment or array of values
SELECT JSON_QUERY(@JSON, '$[0].Language');

-- Default is lax mode - returns NULL on error
-- Strict will raise error

SELECT JSON_QUERY(@JSON, 'lax $[1].Language');
SELECT JSON_QUERY(@JSON, 'strict $[1].Language');

All of the SQL is also posted on GitHub.

Simple Talk has a good introduction to JSON functionality.
Microsoft Docs – OPENJSON
Microsoft Docs – JSON Functions

Decimal vs Numeric

January 22, 2018

When storing exact numeric values with decimal values in SQL Server, there are two data types to choose from: Decimal and Numeric. Both types allow precision and scale to be defined. Precision is the maximum number of total digits allowed, and scale is the number of digits to the right of the decimal point. Both are part of the ANSI standard. Both types appear to be used the same way in SQL Server, the Microsoft documentation states that the two are synonyms. So why are there two data types for the same purpose?
In Joe Celkos’s book “SQL For Smarties”, he mentioned a sight distinction between the two.
“NUMERIC (p,s) specifies the exact precision and scale to be used. DECIMAL(p,s) specifies the exact scale, but the precision is implementation-defined to be equal or greater than the specified value.”
So there’s a slight difference in the ANSI Standard, but no difference in the SQL Server implementation.

I did find it interesting that when that when an error was raised assigning a value to a decimal variable, the error message referred to a numeric data type.

declare @Value decimal(2,1);
set @Value = 123.456;

Msg 8115, Level 16, State 8, Line 25
Arithmetic overflow error converting numeric to data type numeric.

I use decimal, since that term is more specific than numeric, which sounds like it would be any kind of number, even integers.