Security? Is the kind of "security" that you're talking about center around some odd notion that you have proprietary code that you don't want anyone to be able to figure out or steal? If so, have you ever heard of a thing called a "decompiler", which will lay waste to that notion?
If you talking about some form of access security, then you're going about thing the hard way. It's easy to grant someone exec privs for someone to execute a stored procedure without give them privs to see any of the underlying objects, need any privs other than PUBLIC and the privs to execute the proc, or even view the code for the stored procedure.
I'm thinking that converting T-SQL to an SQLCLR is serious overkill here that will cause a fair bit of downstream pain especially when you run into someone like me...
is pronounced "ree-bar
" and is a "Modenism
" for R
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
"If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
"Change is inevitable... change for the better is not."
When you put the right degree of spin on it, the number 3|8
is also a glyph that describes the nature of a DBAs job. 😉
How to post code problems
Create a Tally Function (fnTally)