The last line says it all, though it might offend a few of you. Jeremiah Peschka wrote agreat piece on encrypted stored procedures and telling companies they shouldn't bother. I agree, the arguments given in the comments notwithstanding.
I have heard this argument over and over, from different industries, and in every case where someone has broken down their code, you find it really isn't that special. There's no super secret way to accomplish most anything you're going to put into a stored procedure on a database server. We have to know how things work from a logic standpoint so that we can be sure that the correct data is moving to the correct place. If we know the logic, we can easily build code that does the same thing ourselves. We just don't want to. We buy software so that we don't have to spend the time coding it ourselves.
What about support issues? I have heard this argument quite a few times as well. The answer here is to deal with it administratively. Spell is out in the contract that customers who changes stored procedure will be charged for support issues caused by the change. Heck, everything else is disclaimed or handled in the EULA, why not this?
IMHO, this "feature" ought to just be removed from SQL Server. There's no good reason to encrypt a stored procedure, especially with the SQLCLR available for any of those truly top secret, complex algorithms you think you have.
Steve Jones
The Voice of the DBA Podcasts
The podcast feeds are available at sqlservercentral.mevio.com. Comments are definitely appreciated and wanted, and you can get feeds from there.
You can also follow Steve Jones on Twitter:
or now on iTunes!
- Windows Media Podcast - 23.8MB WMV
- iPod Video Podcast - 17.1MB MP4
- MP3 Audio Podcast - 3.9MB MP3
Today's podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.