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.
"Change is inevitable... change for the better is not".
"If "pre-optimization" is the root of all evil, then what does the resulting no optimization lead to?"
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)