Microsoft SQL server 2016


Why should collation be an issue?


Ensure that the SQL server and the database all have the same collation setting from the beginning – and try to not change it.

But some products demand a specific collation setting (like cognos) – that is equal to the SQL server.

To get around differences, between databases, in each select statement use collate;

ProductDesc D ON P.Pcode=D.Pcode collate SQL_Latin1_General_CP1_CI_AS


More information:

The Windows collation can use an index while comparing unicode and non-unicode, such as nvarchar to varchar, with a slight performance cost. The SQL collation cannot use the index while comparing data in such scenarios.

Some characters that are treated as independent letters. For example, operator LIKE ‘%ß%’ will return that exact match in SQL collation, while Windows collation will also return LIKE ‘%ss%’ as the expanded character of ß to ss.

Mixing collations within the database can cause errors such as this: ‘Cannot resolve the collation conflict between “SQL_Latin1_General_CP1_CI_AS” and “Latin1_General_CI_AI” in the equal to operation.’

Collation can be specified in a statement to instruct the SQL engine to use such collation ad-hoc (e.g. SELECT * FROM SomeTable WHERE SomeField COLLATE SQL_Latin1_General_CP1_CI_AS = N’ßeta’)


Microsoft SQL server 2016


When you try to script out the database schema, to be able to create a empty database on other server, we get a error when we select to much. If you have more than 42000 views in a database you will get issues with the wizard.

The wizard – Generate Scripts – from task menu on the database, will give error if the database contain to many objects.

Can also be a an issue if you use an older versions of SSMS or that you have encrypted SP in the database.

SSMS can crash when you try to generate the script with to many objects selected.


Manually script out all the views in a table.

select schema_name(v.schema_id) as schema_name, as view_name,

       v.create_date as created,

       v.modify_date as last_modified,


from sys.views v

join sys.sql_modules m 

     on m.object_id = v.object_id

 order by schema_name,



Then copy the result from the table column to a new query window for the new database.

Change that each line (command) end with ;

Then run the new SQL statements, to recreate the views in the new database.

More information:


Microsoft SQL server


What version of SQL server is it?

The different tools to SQL server are often installed in folder C:\Program Files\Microsoft SQL Server\150, where the number represent the version of SQL server.

The Database default folder is C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA, where the number 15 represent the SQL version – in this example that is SQL server 2019.


This page show the version numbers:

SQL Server Version Internal Database Version Database Compatibility Level Supported Database Compatibility Levels
SQL Server 2022 950 160 ?
SQL Server 2019 CTP 3.2 / RC 1 / RC 1.1 / RTM 904 150 150,140,130,120,110,100
SQL Server 2019 CTP 3.0 / 3.1 902 150 150,140,130,120,110,100
SQL Server 2019 CTP 2.3 / 2.4 / 2.5 897 150 150,140,130,120,110,100
SQL Server 2019 CTP 2.1 / 2.2 896 150 150,140,130,120,110,100
SQL Server 2019 CTP 2.0 895 150 150,140,130,120,110,100
SQL Server 2017 868 / 869 140 140,130,120,110,100
SQL Server 2016 852 130 130,120,110,100
SQL Server 2014 782 120 120,110,100
SQL Server 2012 706 110 110,100,90
SQL Server 2012 CTP1
(a.k.a. SQL Server 2011 Denali)
684 110 110,100,90
SQL Server 2008 R2 660 / 661 100 100,90,80
SQL Server 2008 655 100 100,90,80
SQL Server 2005 SP2+
with VarDecimal enabled
612 90 90,80,70
SQL Server 2005 611 90 90,80,70
SQL Server 2000 539 80 80,70
SQL Server 7.0 515 70 70
SQL Server 6.5 408 65 65
SQL Server 6.0 406 60 60

Legend: ? = still investigating, RTM = Release to manufacturing, SPn = Service Pack n, CTP = Community Technology Preview (beta release).


To see the compatibility level on the database enter:

EXEC sp_helpdb;


Microsoft SQL server 2016

Visual Studio developing


When deploy/publish a database change to a SQL server 2016 we get a error;

The remote script failed with exit code 1

The action Publish DacPac on server failed

Could not find the file: Microsoft.SqlServer.Dac.dll

Possible solution:

Check on the target SQL server if the needed files are installed in correct folder.

Depending on version of SQL server, the files are in folders like 120,130,140.

Folder 150 is for SQL server 2019.

For SQL server version 2016 the files should be in folder 130

C:\Program Files\Microsoft SQL Server\130\dac\bin

If the folder is missing, check what version of SQL server that is installed.

Can be that SQL server is installed, but the supporting tools like Microsoft SQL Server Data Tools and Microsoft SQL Server Data-Tier Applications Framework (x64) is installed, but at an different version.

Go to control panel – program and features – and check what is installed.

Download and install the correct version you need.


More information:



Microsoft SQL server 2016


A rollback of a deadlock is hung on itself. You have try to kill a process that was hung, but not it is stuck in suspended state.

Suggested solution:

Go to SSMS – Activity Monitor – sort on the Command column to find the rollback processes. Note down the ID

Check if this process is doing anything with this command:

select percent_complete, * from sys.dm_exec_requests where session_id = 69  -- change to your id

If the values does not change from 0%, then the process is most likely not doing anything.

From the result of above statement, you can of wait_resource column find out what table is creating the lock.

wait_resource = “KEY: 40:844424931901440 (7210abc) ” =  Database_Id, HOBT_Id

The first number is the database – use this SQL query to find what:

SELECT     name    FROM    sys.databases    WHERE      database_id=40;

The second number is the table that gives the issue – use this SQL query in the database to find where:

SELECT as schema_name, as object_name, as index_name

FROM sys.partitions AS p

JOIN sys.objects as so on 


JOIN sys.indexes as si on 

    p.index_id=si.index_id and 


JOIN sys.schemas AS sc on 


WHERE hobt_id = 844424931901440;


If you can not find the other blocking process and stop it, and a recreate of a index does not help, then your option is to restart the SQL server service in Microsoft Windows.

Obtain some downtime on the SQL server, and restart the service in hope it will solve the deadlock.

More information:


Microsoft SQL server 2016


Get a warning when you create a table with a primary key.

Warning! The maximum key length for a clustered index is 900 bytes. The index ‘xyz’ has maximum length of 8024 bytes. For some combination of large values, the insert/update operation will fail.

CREATE TABLE [fun_table]

([the_name] [nvarchar](100) NULL,

[the_value] [sql_variant] NOT NULL,  -- will give the error


([the_value] ASC




Suggested solution:

Change the sql_variant to a nvarchar() instead if you are going to use it in a index.  This is a warning that if you store more than 900 bytes in the column the_value, it will be truncated at the index/primary key.

More information:

From the internet – but this facts change with what version of Microsoft SQL server you are using.

As a general rule, you should avoid using SQL Server’s sql_variant data type. sql_variant is limited:

  • Variants can’t be part of a primary or foreign key in SQL server before 2005.
  • Variants can’t be part of a computed column.
  • Variants won’t work with LIKE in a WHERE clause.
  • OLE DB and ODBC providers automatically convert variants to nvarchar(4000)

To avoid problems, always explicitly convert sql_variant data types as you use them.

But some people claim that SQL_VARIANT is a fair bit faster than going trough VARCHAR conversions for your columns.

Warning! The maximum key length is 900 bytes. The index has maximum length of 1000 bytes. For some combination of large values, the insert/update operation will fail.