SSDT - Support T-SQL parameter defaults for SQLCLR objects via the SqlFacet attribute when generating the publish and create SQL scripts - by Solomon Rutzky

Status : 

 


11
0
Sign in
to vote
ID 1571539 Comments
Status Active Workarounds
Type Suggestion Repros 2
Opened 7/20/2015 10:25:51 PM
Access Restriction Public

Description

Currently there is no way to specify that any input or output parameters to a SQLCLR stored procedure or function should be optional and have a default value.
The T-SQL wrapper objects (i.e. "CREATE {object} ... AS EXTERNAL NAME {Assembly}.{Class}.{Method};" ) do allow for default values to be specified
(except for the LOB types: NVARCHAR(MAX), VARBINARY(MAX), and XML), but there is no way to indicate that to the SSDT publishing process.

In order to set a parameter default value, you need to either update the SQL script that has the CREATE statement (prior to deployment)
 or issue an ALTER PROCEDURE / ALTER FUNCTION statement post-deployment.
Sign in to post a comment.
Posted by jyao on 2/19/2017 at 10:48 AM
It is always two sides opinion, from MS side, MS thinks no many people are using CLR inside SQL Server, but on the other hand from user side, if MS does not make CLR easier and more comprehensive, how would you expect people to use it?

This is a great suggestion and I hope MS can solve it.
Posted by Pxtl on 3/23/2016 at 1:26 PM
Because with no function overloading, optional parameters is the only way to provide multiple calling signatures for a function is defaults... which you refuse to implement.

Does anybody at Microsoft actually *use* SSDT and SQLCLR?
Posted by Microsoft on 8/3/2015 at 10:28 AM
Hi Solomon,

Thanks for submitting this feedback. Your suggestion makes a lot of sense. Unfortunately, we've evaluated this suggestion relative to our other development tasks and decided not to implement support for this functionality at this time. We appreciate that you took the time to submit this feedback, and we hope you'll continue to share your ideas for improving our SQL Server tools in the future.

Regards,
Steven Green
SQL Server developer tools team