Question

Background:

Visual studio fails at deploying a database project. It tries to drop functions that are already referenced (e.g. in a check constraint), rather than just adding the new ones and updating the existing ones, so the deployment always fails.

As a result, I’m writing my own code to update the assembly and add/update any functions.

I assume the compiler/deployer uses reflection and properties of the SqlFunction attribute, so I’m also using reflection to gather a MethodInfo list of the static methods that have the SqlFunction attribute.

Question/Task:

I need to know how to translate the SqlFunctionAttribute’s properties (e.g. IsDeterministic, DataAccess, Name, IsPrecise, etc.) and the method signature of the function into an appropriate T-SQL “CREATE FUNCTION” statement.

Existing information I’ve already found to be not helpful:

The documentation for ‘create function’ is confusing and incomplete. Towards the bottom it finally mentions some of the SqlFunction properties like IsDeterministic, but it talks about them like they’re C# properties, not T-SQL parameters, so I have no idea how to use them in a create function statement.

//CLR Functions
CREATE FUNCTION [ schema_name. ] function_name 
( { @parameter_name [AS] [ type_schema_name. ] parameter_data_type 
        [ = default ] } 
    [ ,...n ]
)
RETURNS { return_data_type | TABLE <clr_table_type_definition> }
    [ WITH <clr_function_option> [ ,...n ] ]
    [ AS ] EXTERNAL NAME <method_specifier>
[ ; ]

I would expect the clr_function_option parameter to handle things like IsDeterministic, but it’s not listed as an option.

Meanwhile, in documentation for IBM DB2, I see statements like the following, which the MSDN documentation has nothing remotely similar:

  CREATE FUNCTION countUp(INTEGER) 
  RETURNS INTEGER
  LANGUAGE CLR
  PARAMETER STYLE SQL
  SCRATCHPAD 10
  FINAL CALL
  NO SQL
  FENCED
  THREADSAFE
  NOT DETERMINISTIC
  EXECUTION CONTORL SAFE
  EXTERNAL NAME 'gwenUDF.dll:bizLogic.empOps!CountUp' ;

Answer 1

I solved this problem eventually, after realizing that SQL Server, possessing the assembly itself, has access to the SqlFunctionAttribute’s property values. In that case, there is no need to (and is no syntax for) specifying such properties in the “CREATE FUNCTION” T-SQL statement.

I built a utility to automatically enumerate and deploy functions and check-constraints which works like this:

1. It enumerates all deployable static methods in classes that I specify, by searching for functions having an SqlFunction attribute using reflection. It also runs a query to enumerate all existing scalar and table-valued assembly functions already deployed. It then merges these lists into a single list, where each function either exists or does not exist. There is a button to update the assembly, and a button to toggle each function’s existence, making adding/removing/updating functions a BREEZE.

2. In addition, I added a second tab to the interface to create/enable/check/disable check-constraints. I created a new attribute called SqlFunctionCheck, which can be applied multiple times to a function. The attribute has a “Table” property and a “Field” property, which helps the utility build the check constraints. It aggregates all the checks by table, create a check for each table named “CK_” + table_name, and creates a constraint expression joining all method calls with “and” passing the associated field name for that table to the function. It displays the generated constraint expression as well as the constraint expression queried from sql server if the constraint already exists.

IMO, this is the ultimate solution for using SQL CLR Integration to enforce data type constraints in management studio, SQL queries in your code, and the data used throughout the code itself from a centralized data (constraint) classes.