I have written a stored procedure in SQL Server.
Now its just that I don't want any one to see my script or edit it.
Please remember that I am working on the a standard login id and password. Which is shared with every one.
Hence some way where I can allow every one to execute the procedure. But they shouldn't see the script.
Cheers! thanks
Well, one word answer is you can hide it with the command WITH ENCRYPTION when you create stored procedure or function.
Using SQL Server Management StudioExpand Stored Procedures, right-click the procedure and then select Script Stored Procedure as, and then select one of the following: Create To, Alter To, or Drop and Create To. Select New Query Editor Window. This will display the procedure definition.
Now, is set nocount off necessary? No, as any new commands executed will be in a different scope, and by default set nocount off is always in effect. But as stated above in comments, it's considered a good practice, just to explicitly indicate that this setting will return to normal when the proc is finished executing.
SET NOCOUNT ON prevents the sending of DONEINPROC messages to the client for each statement in a stored procedure.
You're looking for WITH ENCRYPTION
, which encrypts the code behind your stored proc.
CREATE PROCEDURE usp_MyProc
WITH ENCRYPTION
AS
SELECT *
FROM myTable
Just a caveat, from MSDN:
Users who have no access to system tables or database files cannot retrieve the obfuscated text. However, the text will be available to privileged users who can either access system tables over the DAC port or directly access database files.
Some references and further reading:
SQL Server doesn't truly provide a foolproof method to protect module code. The WITH ENCRYPTION
clause should be named something along the lines of WITH LOOSE_OBFUSCATION
, since the "encryption" is very easily thwarted. You're not going to be able to use anything in SQL Server to make the code undecipherable by anyone except the most casual onlookers - anyone determined is going to be able to beat native methods without breaking a sweat.
While this may be good enough for your needs, probably a safer way (but still not perfect) is to put some or all of the procedure's business logic into the CLR (read more here).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With