Let’s see it in the action:

DECLARE @Message NVARCHAR(MAX) = 'String1:%s, String2:%s, String3:%s'
DECLARE @StringA NVARCHAR(MAX)
DECLARE @StringB NVARCHAR(MAX)
DECLARE @StringC NVARCHAR(MAX)

SET @StringA = REPLICATE('A', 1000)
SET @StringB = REPLICATE('B', 1000)
SET @StringC = REPLICATE('C', 1000)

-- print the message
PRINT FORMATMESSAGE(@Message, @StringA, @StringB, @StringC)

-- get message string length
SELECT LEN(FORMATMESSAGE(@Message, @StringA, @StringB, @StringC))

-- compare to RAISERROR()
RAISERROR(@Message, 10, 1, @StringA, @StringB, @StringC)
GO

It is pretty well visible how the message was shortened from expected more than 3k characters to the 2044 characters maximum and ellipsis added. RAISERROR() returns exactly the same result.

Why does this matter? Consider an example where you would like to build i.e. JSON string and you will decide to build individual keys like this:

USE [msdb]
GO

DECLARE @Pattern NVARCHAR(MAX)

SET @Pattern = '{"Table_Id": %i, "Table_Name": "%s", "Columns": [ %s ] }'

SELECT 
	[a].[JSON_Row], LEN([a].[JSON_Row]) Characters
FROM (
		SELECT 
			FORMATMESSAGE(@Pattern, t.[object_id], t.[name], STRING_AGG('{ "Name": "' + c.[name] + '", "Datatype": "' + tp.[name] + '" }', ',')) JSON_Row
		FROM sys.[tables] t
			INNER JOIN sys.[columns] c ON [c].[object_id] = [t].[object_id]
			INNER JOIN sys. tp ON [tp].[system_type_id] = [c].[system_type_id] AND [tp].[user_type_id] = [c].[user_type_id]
		GROUP BY t.[object_id], t.[name]
	) a
ORDER BY Characters DESC
GO

Two rows marked exceeded the maximum 2044 allowed length for FORMATMESSAGE() output and their value was silently shortened in the background and if you will try to parse the JSON later you might get an error but not all the time, only when you hit the invalid part of the JSON (which makes things getting much worst then it looks like):

DECLARE @Pattern NVARCHAR(MAX)

SET @Pattern = '{"Table_Id": %i, "Table_Name": "%s", "Columns": [ %s ] }'

SELECT 
	-- JSON_VALUE([a].[JSON_Row], '$.Table_Id') -- This will work
	JSON_VALUE([a].[JSON_Row], '$.Columns') -- This will fail
FROM (
		SELECT 
			FORMATMESSAGE(@Pattern, t.[object_id], t.[name], STRING_AGG('{ "Name": "' + c.[name] + '", "Datatype": "' + tp.[name] + '" }', ',')) JSON_Row
		FROM sys.[tables] t
			INNER JOIN sys.[columns] c ON [c].[object_id] = [t].[object_id]
			INNER JOIN sys. tp ON [tp].[system_type_id] = [c].[system_type_id] AND [tp].[user_type_id] = [c].[user_type_id]
		GROUP BY t.[object_id], t.[name]
	) a
--WHERE LEN([a].[JSON_Row]) <= 2047 -- This will remove invalid rows and keep it finish
GO

It’s more than obvious that ignoring basic facts highlighted in the official SQL Server documentation may let you scratch the head for several hours:)

This function is designed to provide aggregations across large data sets where responsiveness is more critical than absolute precision. It evaluates an expression for each row in a group and returns the approximate number of unique non-null values in a group.

It accepts an expression of any type, except image, sql_variant, ntext, or text.

Internally it’s optimized for use in big data scenarios for the following conditions:

• Access to data sets that are millions of rows or higher and
• Aggregation of a column or columns that have many distinct values

The function implementation guarantees up to a 2% error rate within a 97% probability using the HyperLogLog algorithm and requires less memory than an exhaustive COUNT DISTINCT operation. Having a smaller memory footprint will the function less likely to spill memory to disk compared to a precise COUNT DISTINCT operation.

Let us try in on AdwentureWorksLT sample database running on Azure SQL:

SELECT 
	COUNT(DISTINCT [ProductID]) AS [Distinct_ProductIDs],
	APPROX_COUNT_DISTINCT([ProductID]) AS [Approx_Distinct_ProductIDs]
FROM [SalesLT].[SalesOrderDetail]
GO

SELECT 
	[ProductID], 
	COUNT(DISTINCT [LineTotal]) AS [Distinct_Line_Total_Per_ProductID], 
	APPROX_COUNT_DISTINCT([rowguid]) AS [Distinc_LineTotal_Per_ProductID]
FROM [SalesLT].[SalesOrderDetail]
GROUP BY [ProductID]
ORDER BY [ProductID]
GO

The result is quite interesting for anyone who will expect that for smaller data sets APPROX_COUNT_DISTINCT will return the same result as COUNT DISTINCT. Not exactly – significant differences are theRE, i.e. row 6 for Product_ID = 715 – there is double value to be approximated. So there is really no reason to not use COUNT DISTINCT for smaller data set where the overhead is minimal.  APPROX_COUNT_DISTINCT will make a great job on a really large data set where we need to do raw estimates of rows count and running the precise COUNT DISTINCT will consume a huge amount of system resources.

But there is also an option to use a third parameter called function specified in BOL as:

• Function is the type of operation to perform.
• Function must be tinyint, smallint, or int.
• When function is omitted or has a value of 0 (default), numeric_expression is rounded.
• When a value other than 0 is specified, numeric_expression is truncated.

Let’s observe this simple example:

SELECT 'ROUND down', ROUND(5.1, 0) UNION ALL
SELECT 'ROUND up', ROUND(5.9, 0) UNION ALL
SELECT 'TRIM only', ROUND(5.1, 0, 1) UNION ALL
SELECT 'TRIM only', ROUND(5.9, 0, 1)
GO

Using the third parameter with a different value than 0 we have simply trimmed decimal places which can be really handy in case of some specific need for reporting when there is a requirement to report numbers without decimal place but also have a proper value at the total row.

Let me mention one important thing we should remember using the ROUND()  function.

Consider the following example:

SELECT ROUND(9.9, 0)
GO

Are you surprised about this error?

The explanation is easy: value 9.9 is handled in this case as to be DECIMAL(2,1). Rounding it to 0 decimal places means that the new value will be 10 and this doesn’t fit into the original DECIMAL(2,1) data type.

This can be easily fixed like this:

SELECT ROUND(CAST(9.9 AS DECIMAL(3,1)), 0)
GO

I saw a lot of production disasters caused by this simple piece of code during my career.

A simple demonstration of the situation:

DECLARE @String1 NVARCHAR(200) 
DECLARE @String2 NVARCHAR(200) 

SET @String1 = '<tsql_stack><frame database_name = ''Custom_PL''/></tsql_stack>'
SET @String2 = '<tsql_stack><frame database_name = ''Custom_Pl''/></tsql_stack>'

SELECT @String1 AS StringValue
UNION
SELECT @String2

SELECT HASHBYTES('SHA2_256', @String1) HashValue
UNION
SELECT HASHBYTES('SHA2_256', @String2)
GO

We have declared two string variables and set the value of both to the “magical” string. Then we are comparing these two strings using the UNION operator and the result is as expected: only one row is returned. But when we do the same with hashes we can see two different values instead of a single one like with the previous UNION:

What’s going wrong?

Oki. Let’s stop joking. I will give you small help:

SELECT CONVERT (varchar, DATABASEPROPERTYEX(DB_NAME(),'collation')) Collation

Any idea? I have one: don’t trust what you see: double-check our strings:

Do you see it? There is the same letter “L” one time as capital and other times the lower case.

If you will check the collation then it’s obvious: CI = case insensitive which means that the UNION statement will compare these two strings as equal. Bit this isn’t true for the SHA2_256 algorithm which is a binary function knowing zero about case sensitivity.

Don’t trust what you see:)

Pojďme si ukázat, jak STRING_AGG() funguje v praxi.K tomu si nejprve vytvoříme jednoduchá testovací data: objednávky a jejich položky:

DROP TABLE [dbo].[OrderItems]
DROP TABLE [dbo].[Orders]
GO

-- create sample tables
CREATE TABLE dbo.Orders
(
    Id INT IDENTITY(1,1) PRIMARY KEY,
    OrderDate DATETIME NOT NULL
)
GO

CREATE TABLE dbo.OrderItems 
(
    Id INT IDENTITY(1,1) PRIMARY KEY,
    OrderId INT NOT NULL REFERENCES dbo.Orders,
	ProductName VARCHAR(100) NOT NULL,
    Amount INT NOT NULL,
    Price INT NOT NULL,
    Note VARCHAR(50)
)
GO

-- populate tables with data
INSERT dbo.Orders VALUES ('2018-01-01')
INSERT dbo.Orders VALUES ('2018-02-02')
INSERT dbo.Orders VALUES ('2018-03-03')
INSERT dbo.Orders VALUES ('2018-03-04')
GO

INSERT dbo.[OrderItems]
	( [OrderId], [ProductName], [Amount], [Price], [Note] )
    SELECT Id, 'ProductA', 10, 1500, 'NoteOrderItem1' FROM dbo.Orders WHERE [Id] = 1 UNION ALL
    SELECT Id, 'ProductB', 5, 750, 'NoteOrderItem2' FROM dbo.Orders WHERE [Id] = 1 UNION ALL
	SELECT Id, 'ProductC', 3, 500, 'NoteOrderItem3' FROM dbo.Orders WHERE [Id] = 1 UNION ALL
	SELECT Id, 'ProductA', 15, 300, 'NoteOrderItem1' FROM dbo.Orders WHERE [Id] = 2 UNION ALL
	SELECT Id, 'ProductX', 8, 200, 'NoteOrderItem2' FROM dbo.Orders WHERE [Id] = 2 UNION ALL
	SELECT Id, 'ProductF', 15, 300, 'NoteOrderItem1' FROM dbo.Orders WHERE [Id] = 3 UNION ALL
	SELECT Id, 'ProductG', 8, 200, 'NoteOrderItem2' FROM dbo.Orders WHERE [Id] = 3
GO

-- review test data
SELECT * FROM [dbo].[Orders] [o]
SELECT * FROM [dbo].[OrderItems] [oi]
GO

Na daty si postupně vyzkoušíme různé použití STRING_AGG() funkce a to tak, že budeme agregovat hodnoty sloupce ProductName pro jednotlivé objednávky a názvy produktů od sebe oddělíme čárkou:

SELECT o.[Id], o.[OrderDate], 
       STRING_AGG(oi.[ProductName], ', ') Products
FROM dbo.[Orders] [o]
	LEFT JOIN [dbo].[OrderItems] [oi] ON [oi].[OrderId] = [o].[Id]
GROUP BY o.[Id], o.[OrderDate]
GO

Toto je nejjednodušší možné použití funkce STRING_AGG(): prostá agregace hodnot sloupce ProductName za sebou, jednotlivé položky odděleny čárkou. Všimněte si jedné opravu zásadní věci: STRING_AGG() nepřidává separátor za poslední položku v seznamu, což je naprosto úžasné, neboť jinak bychom to v 99% případů ještě obalovali dalším zbytečným kódem, abychom odstranili čásku za poslední položkou.

V rámci funkce STRING_AGG() můžeme používat i různé expressions a se slučovanými řetězci dále libovolně pracovat. V následujícím příkladu např. pomocí ISNULL() šetříme chybějící produkty pro případ, že objednávky nemá žádné položky:

SELECT o.[Id], o.[OrderDate], 
       STRING_AGG(ISNULL(oi.[ProductName], '0 order items'), ', ') Products
FROM dbo.[Orders] [o]
	LEFT JOIN [dbo].[OrderItems] [oi] ON [oi].[OrderId] = [o].[Id]
GROUP BY o.[Id], o.[OrderDate]
GO

Funkci STRING_AGG() můžeme použít i s přídavkem WITH GROUP(), čímž získáme možnost určit pořadí, v jakém budou řetězce spojovány:

SELECT o.[Id], o.[OrderDate], 
       STRING_AGG(ISNULL(oi.[ProductName], '0 order items'), ', ')
           WITHIN GROUP (ORDER BY oi.ProductName DESC) AS Products
FROM dbo.[Orders] [o]
	LEFT JOIN [dbo].[OrderItems] [oi] ON [oi].[OrderId] = [o].[Id]
GROUP BY o.[Id], o.[OrderDate]
GO

Nyní jsou názvy produktů seřazeny podle abecedy obráceně. Pro řazení můžeme používat libovolné dostupné sloupce v rámci dotazu, tedy klidně řadit podle hodnot z jiných tabulek, než ve které je náš agregovaný řetězec.

Myslím, že STRING_AGG() je opravdu podařená funkce a podle mě se stane vůbec nejpoužívanější novinkou v SQL Serveru 2017.

Syntaktické a funkční srovnání všech funkcí ukazuje následující kód:

SELECT ' AAA '
UNION ALL
SELECT LTRIM(RTRIM(' AAA '))
UNION ALL
SELECT TRIM(' AAA ')
GO

TRANSLATE ( inputString, characters, translations) 

• inputString je řetězec, v němž chceme provést nahrazení
• characters jsou znaky, které chceme nahradit
• translactions jsou znaky, které chceme nově vložit

Ukázkový příklad pak vypadá takto:

SELECT 'TRANSLATE(''[Hi]'', ''[]'', ''()'')' FceCall, TRANSLATE('[Hi]', '[]', '()') Result
UNION ALL
SELECT 'TRANSLATE(''[Hi sir]'', ''[sir]'', ''(man)'')', TRANSLATE('[Hi sir]', '[sir]', '(man)')
GO

Na prvním řádku vidíme jednoduché nahrazení dvou různých znaků dvěma novými znaky.

Druhý řádek nám ilustruje, jak se chová celá funkce ještě názorněji: nahrazuje se tu znak za znak, takže jsme sice jakoby nahradili slovo “sir” slovem “man”, ovšem jak vidíme na výstupním řetězci, ve skutečnosti jsme řekli, že chceme každé písmeno “i” nahradit písmenem “a”.

Pokud bychom chtěli řádek 1 zapsat postaru pomocí řetězení REPLACE() funkcí, kód by vypadal takto:

SELECT REPLACE(REPLACE('[Hi]', '[', '('), ']', ')')

Důležité pravidlo, které musíme dodržet je, že hodnoty parametrů characters a translactions musí mít stejnou délku, jinými slovy, musíme mít vždy dvoji starých/nových znaků k nahrazení:

SELECT TRANSLATE('abc', 'ab', 'c')

Porovnejme si nyní obě funkce na jednoduchém příkladu:

DECLARE @String1 NVARCHAR(100) = 'String1'
DECLARE @String2 NVARCHAR(100) = 'String2'
DECLARE @String3 NVARCHAR(100) = 'String3'

SELECT 'CONCAT()' [Function],	 CONCAT(@String1, @String2, @String3) Result
UNION ALL
SELECT 'CONCAT()_WS' [Function], CONCAT_WS(', ', @String1, @String2, @String3)
GO

Dobrá zpráva je, že separátor můžeme zaslat do funkce i jako parametr, čímž získáváme mnohem větší svobodu při psaní kódu:

DECLARE @String1 NVARCHAR(100) = 'String1'
DECLARE @String2 NVARCHAR(100) = 'String2'
DECLARE @String3 NVARCHAR(100) = 'String3'

DECLARE @Separator CHAR(1) = '-'

SELECT 'CONCAT()_WS' [Function], CONCAT_WS(@Separator, @String1, @String2, @String3)
GO

First, create a simple scalar function to play with:

CREATE FUNCTION dbo.f_MergeStrings(
	@String1 VARCHAR(100),
	@String2 VARCHAR(100)
)
RETURNS VARCHAR(200)
AS
BEGIN
	RETURN @String1 + @String2
END
GO

There is no magic: two input strings are concatenated to one.

1. SELECT

SELECT dbo.f_MergeStrings('AB', 'CD')
GO

I will say this is the most common way how we are calling scalar functions to get the result. For sure there can be a complex SELECT statement and a scalar function can be called anywhere inside it where expressions are allowed (in place of columns in SELECT, WHERE, joins, etc.)

For sure we can assign a scalar function return value to another variable:

DECLARE @FinalString VARCHAR(200)

SELECT @FinalString = dbo.f_MergeStrings('AB', 'CD')

PRINT @FinalString
GO

2. SET

SET works very similar to SELECT:

DECLARE @FinalString VARCHAR(200)

SET @FinalString = dbo.f_MergeStrings('AB', 'CD')

PRINT @FinalString
GO

There is one exception: it can´t be called without assigning value to a variable like (syntax error)

SET dbo.f_MergeStrings('AB', 'CD')
GO

3. EXECUTE

Yes, you can call the scalar function using EXECUTE without all the parentheses as you do it for stored procedures:

DECLARE @FinalString VARCHAR(200)

EXEC @FinalString = dbo.f_MergeStrings 'AB', 'CD'

PRINT @FinalString
GO

You can also use long-form with full parameter names:

DECLARE @FinalString VARCHAR(200)

EXEC @FinalString = dbo.f_MergeStrings @String1 = 'AB', @String2 = 'CD'

PRINT @FinalString
GO

It´s really funny that you can execute a scalar function the way that nothing is returned to the client – the result is completely lost:

EXEC dbo.f_MergeStrings @String1 = 'AB', @String2 = 'CD'
GO

You can use a lot of the clauses supported by EXECUTE:

DECLARE @FinalString VARCHAR(200)

EXEC @FinalString = dbo.f_MergeStrings 'AB', 'CD' WITH RECOMPILE

EXEC @FinalString = dbo.f_MergeStrings 'AB', 'CD' WITH RESULT SETS UNDEFINED

EXEC @FinalString = dbo.f_MergeStrings 'AB', 'CD' WITH RESULT SETS NONE
GO

Except RECOMPILE they don´t have any effect because there is no result set to be returned.

If you will try set an explicit result set the statement will fail and the error message is clear:

DECLARE @FinalString VARCHAR(200)

EXEC @FinalString = dbo.f_MergeStrings 'AB', 'CD' WITH RESULT SETS (([String] NVARCHAR(20)))
GO

Using dynamic SQL you can run the code under different security context:

EXEC ('DECLARE @FinalString VARCHAR(200); 
	   EXEC @FinalString = dbo.f_MergeStrings ''AB'', ''CD''; 
	   PRINT @FinalString') AS LOGIN = 'SQLpowered'
GO

And If you want you can wrap it to sp_executesql:

DECLARE @String1 VARCHAR(100)
DECLARE @String2 VARCHAR(100)
DECLARE @FinalString VARCHAR(200)
DECLARE @Params NVARCHAR(500)

SET @String1 = 'AB'
SET @string2 = 'CD'

SET @Params = N'@String1 VARCHAR(200), @String2 VARCHAR(200), @FinalString VARCHAR(200) OUTPUT'

EXECUTE sp_executesql N'EXEC @FinalString = dbo.f_MergeStrings @String1, @String2', @Params, 
						@String1 = @String1, @String2 = @String2, @FinalString = @FinalString OUTPUT

PRINT @FinalString
GO

Which method is the best? I will say the SET and SELECT are something we are familiar with. EXECUTE is most of the time used for calling stored procedures or dynamic SQL and it can be a big surprise for people to see it used with scalar functions.

Further reading:

• When to use SET vs SELECT when assigning values to variables in SQL Server (mssqltips.com)
• http://vyaskn.tripod.com/differences_between_set_and_select.htm

First we will create dbo.SampleTable with simple data inside:

CREATE TABLE [dbo].[SampleTable] 
(
 [ID] INT NOT NULL IDENTITY(1,1) PRIMARY KEY,
 [Value] NVARCHAR(100)
)
GO

INSERT INTO [dbo].[SampleTable]
 VALUES ('A'), ('B'), ('C'), ('D')
GO

SELECT * FROM [dbo].[SampleTable]
GO

As next create simple inline table valued function to return all data from dbo.SampleTable:

CREATE FUNCTION [dbo].[ft_ChangeValue]()
RETURNS TABLE
AS
RETURN 
(
	SELECT [ID], [Value]
	FROM [dbo].[SampleTable]
)
GO

We will test DML operations firing them against our function now:

INSERT:

SET IDENTITY_INSERT [dbo].[SampleTable] ON

INSERT INTO [dbo].[ft_ChangeValue]() (ID, VALUE)
	VALUES (5, 'E from function')

SET IDENTITY_INSERT [dbo].[SampleTable] OFF
GO

SELECT * FROM [dbo].[SampleTable]
GO

UPDATE:

UPDATE [chv]
	SET [chv].[Value] = 'C updated'
FROM [dbo].[ft_ChangeValue]() [chv]
WHERE [ID] = 3
GO

SELECT * FROM [dbo].[SampleTable]
GO

DELETE:

DELETE FROM [dbo].[ft_ChangeValue]()
WHERE [ID] = 2
GO

SELECT * FROM [dbo].[SampleTable]
GO

One question can be obvious: How this works with parameters? Pretty well.

We will modify our function to include @ID as a parameter and filter dbo.SampleRows by this value:

CREATE FUNCTION [dbo].[ft_ChangeValue](
	@ID INT
)
RETURNS TABLE
AS
RETURN 
(
	SELECT [ID], [Value]
	FROM [dbo].[SampleTable]
	WHERE ID = @ID
)
GO

And DML operations:

INSERT:

SET IDENTITY_INSERT [dbo].[SampleTable] ON

INSERT INTO [dbo].[ft_ChangeValue](NULL) (ID, VALUE)
	VALUES (5, 'E from function with parameter')

SET IDENTITY_INSERT [dbo].[SampleTable] OFF
GO

SELECT * FROM [dbo].[SampleTable]
GO

Instead of the NULL parameter value we can use any value but it has no effect on INSERT operation. With UPDATE and DELETE operation there is more fun and @ID value is really useful:

UPDATE:

UPDATE [chv]
	SET [chv].[Value] = 'C updated from function with parameter'
FROM [dbo].[ft_ChangeValue](3) [chv]
GO

SELECT * FROM [dbo].[SampleTable]
GO

DELETE:

DELETE FROM [dbo].[ft_ChangeValue](2)
GO

SELECT * FROM [dbo].[SampleTable]
GO

Conclusion: Yes, it works. BUT: For 99% of people it will be surprise to see this to be used. It is not intuitive enough and I will say slightly against the nature of the SQL standards. Plus we are limited there by lack of implementation of few features we can use with views like WITH CHECK OPTION.