Click here to Skip to main content
13,352,408 members (37,044 online)
Click here to Skip to main content
Add your own
alternative version


57 bookmarked
Posted 29 Jul 2009

How Do I Protect My Stored Procedure Code

, 29 Jul 2009
Rate this:
Please Sign up or sign in to vote.
This article will demonstrate the best practice to protect SQL server code object.


Every developer is exceptionally concerned about how she/he can formulate the best security of her/his SQL code object like a view / storedProcedure as well. For this reason, we will go for encryption. Encryption is a good but not utterly tenable process. In this article, I would like to show you some best practices to protect SQL server code object.

Don't Encrypt Unless Absolutely Necessary

When you distribute SQL Server-based applications to customers and other third parties, you may be tempted to encrypt the source to your stored procedures, functions, and similar objects. Obviously this protects your code from prying eyes and keeps people from making changes to your code without your knowledge.

That said, unless you have real concerns about confidential or proprietary information being stolen, I recommend against encrypting your SQL Server objects. To me, encrypting SQL Server objects is usually more trouble than it's worth. There are a number of disadvantages to encrypting the source code to SQL Server objects. Let's discuss a few of them.

One, encrypted objects cannot be scripted, even by Enterprise Manager. That is, once a procedure or function is encrypted, you cannot retrieve its source from SQL Server. The well-known but undocumented methods of decoding encrypted source in earlier versions of SQL Server no longer work, and other methods one might discover are not supported by Microsoft. To make matters worse, if you attempt to script an encrypted object via Enterprise Manager using the default options, your new script will have a DROP statement for the object, but not a CREATE. Instead, all you'll see is a helpful comment informing you that scripting encrypted objects isn't supported (whereas, obviously, dropping them is). If you run this script, your object will be lost. It will be dropped, but not recreated.

Two, encrypted objects cannot be published as part of a SQL Server replication. If your customers set up replication operations to keep multiple servers in synch, they'll run into problems if you encrypt your code.

Three, you can't check encrypted source code for version info (such as that inserted by a source code management system). Because customers can load backups that may reinstall an older version of your code over a newer one, it's extremely handy to be able to check the code for version info on the customer's server. If your code is encrypted, you can't easily do this. If it's not, and if you've included version information in the source code, you should be able to easily determine the exact version of an object the customer is using.

How Do I Protect My Stored Procedure Code?

When deploying applications to a client's server(s) or to a shared SQL Server, there is often a concern that other people might peek at your business logic. Since often the code in a stored procedure can be proprietary, it is understandable that we might want to protect our T-SQL work. There is a trivial way to do this in SQL Server, instead of:

     SELECT 'SQL statements'


You can use the WITH ENCRYPTION option:

     SELECT 'SQL statements' 

Now, before you do this, make sure you keep the logic of the stored procedure in a safe place, since you won't have easy access to the procedure's code once you've saved it.

Now you will notice that when you try to open the procedure in Enterprise Manager's GUI, you will receive the following error:

Microsoft SQL-DMO 
Error 20585: [SQL-DMO] 
    Encrypted object is not transferable, 
    and script can not be generated. 

And when you try to use sp_helptext to review the code...

EXEC sp_helptext 'Example' 

... you will get the following error:

The object comments have been encrypted. 

Unfortunately, there are at least two ways to defeat this mechanism. One is to run SQL Profiler while executing the stored procedure; this often can reveal the text of the procedure itself, depending on what the stored procedure does (e.g. if it has GO batches, dynamic SQL, etc.). If they miss the initial install, the user can delete the stored procedures or drop the database, start a Profiler trace, and ask you to re-create them (in which case they will capture the CREATE PROCEDURE statements). You can prevent Profiler from revealing the text to snoopers by embedding sp_password in the code, as a comment:

     SELECT 'SQL statements' 
    -- comment: sp_password 


For more about this topic can be found at this link.


I hope that this article might be helpful to you. Enjoy!


  • 30th July, 2009: Initial post  


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Md. Marufuzzaman
Bangladesh Bangladesh
A well experienced leader with successful track record of software development, product innovations, brand management and corporate communication etc. Some successful product innovations have also achieved and awards “Most Valuable Professional” (MVP) at 2010 and 2011 by and also selected as a mentor of Published over 100 technical articles in various software development resource sites (i.e.,, Microsoft MSDN, and IEEE & IBM (In progress)) and various IT Forums, Blogs etc.

Over twelve years of professional experiences in ICT field having extensive experience in formulating corporate vision and long term strategy. Leading development related functions including design, development, services, data management and analytics, customer experience management, content services, digital analytics and optimization.I have also more than two years’ of strong experience in mobile-VAS (platform development).

An individual with results-driven approach and relentless in pursuit of excellence from a business and organizational standpoint.Honest, believes in transparency, commitment and teamwork.

Expertise: Software/Solution Architect, Research, MIS, Data Analytics, Data Mining, BI, SaaS platform base application development, Large scale Win32 Form/Web based business software solutions, Security, Enterprise applications development, integration, etc.

Technologies/Tools: Microsoft.Net version 05/08/10/12, Microsoft SQL Server version 7/2K/05/08/12/14 , Oracle version 10/11, MySql version 5.1, 5.5, 5.7, Visual C#, VB.NET, ASP.NET, API, MVC, WebAPI , WPF, WCF, PHP, Microsoft Power BI, SPSS, PS2, R, Add-In, Visual Basic etc.

.Net UI component: Telerik, DevExpress, Ext.Net.
Scripting language: JavaScript, AngularJS, node.JS.
Source control / Subversion: Git,SVN.
Development methodologies: Agile,RAD.
Project Management / Issues Tracking Tools: JIRA, ClockingIt.

You may also be interested in...


Comments and Discussions

Generalgood job Pin
Rajesh Naik Ponda Goa12-Oct-09 3:29
memberRajesh Naik Ponda Goa12-Oct-09 3:29 
GeneralRe: good job Pin
Md. Marufuzzaman12-Oct-09 4:26
groupMd. Marufuzzaman12-Oct-09 4:26 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.180111.1 | Last Updated 29 Jul 2009
Article Copyright 2009 by Md. Marufuzzaman
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid