Assume that you have a Transact-SQL stored procedure such as the following that takes a table-valued parameter (TVP) that has a constraint as an argument:
create type TestTvpType as table
id int primary key, -- UNIQUE will also do the trick
create procedure TestTvpProc @tvp TestTvpType readonly
select * from @tvp;
In a scenario where this procedure is called from a SQLCLR stored procedure and the constraint is violated for the argument, you may incorrectly receive a system assert, when you would expect to receive a "constraint violation" error message.
The following is an example of a SQLCLR procedure producing a constraint violation for the stored procedure:
public static void ClrProcCallingTsqlProcWithTvpArgument(out int sum)
using (SqlConnection connection = new SqlConnection("context connection=true"))
sum = 0;
DataTable myDataTable = new DataTable("TestTvpType");
// Populate the TVP so it will trigger a PRIMARY KEY VIOLATION error
SqlParameter parameter = new SqlParameter();
parameter.ParameterName = "@tvp";
parameter.SqlDbType = System.Data.SqlDbType.Structured;
parameter.Value = myDataTable;
SqlCommand command = new SqlCommand("TestTvpProc", connection);
command.CommandType = CommandType.StoredProcedure;
using (SqlDataReader reader = command.ExecuteReader())
This issue is fixed in the following cumulative updates for SQL Server:
Note This update causes the return of the correct "constraint violation" error message.
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
Learn about the terminology Microsoft uses to describe software updates.