February 24, 2015 at 1:22 am
I have created several CLR functions which I have assigned to the schema 'fn', rather than the default 'dbo', via a post-deployment script.
As far as I know, it is not possible to specify the schema directly within the database project (other than the project-level 'Default schema'). Is this still the case?
This solution seems clunky. If I add other functions which rely on the existence of the 'fn.' functions, I (unsurprisingly) get Build warnings, because the 'fn' functions do not exist at build time.
Does anyone know whether there are plans to address this? Or perhaps there is a workaround I do not know about?
Edit: Sorry about the title of this post. It would have been better as
Creating CLR functions in non-default schemas
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
March 3, 2015 at 4:46 am
As no one has responded, I will assume that I have not missed anything.
It's a grotty workaround because all of my CLR functions get dropped, created and schema-moved every time the DB is published.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
February 16, 2016 at 9:22 am
See response to issue here: http://stackoverflow.com/questions/34770688/vs-sqlclr-function-x-has-unresolved-reference-to-schema-y
Essentially you add a CREATE SCHEMA object to your project, even if you know the target system will already have the schema.
February 16, 2016 at 9:54 am
Ronzo (2/16/2016)
See response to issue here: http://stackoverflow.com/questions/34770688/vs-sqlclr-function-x-has-unresolved-reference-to-schema-yEssentially you add a CREATE SCHEMA object to your project, even if you know the target system will already have the schema.
It's certainly related to my problem, though not the same, I think.
The critical difference relates to the fact that I wanted to create the CLR functions in a non-default schema. This one small detail changes everything.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply