Jeff,

I agree with you and I believe that encryption keeps competitors just that.

Take Quest LiteSpeed for SQL Server as an example. It is evolved into one of the best backup, restore and Log Shipping application for SQL Server. The Failover and Failback process is very competent. Even MS internal version at SS-2008 cannot touch the maturity of LiteSpeed. Quest charges alot to support their product and the money goes into creating bug fixes and new features so your comment that everything that has been written for SQL Server already exist is only partially correct. Therefore, they should protect their T-SQL code for they have real money invested in this product and the product has commecial benefit and a future.

Just like the patent person who made the same comment over 70 years ago that everything that is worth inventing has already been invented was DEAD WRONG, so are similar comments here !

There will always be creative Developing DBA(s) who will build a better mouse trap and I have clearly been one of them.. Yes I have seen other ideas on various subject and then I have turned them around into some very interesting T-SQL code that I know hit the spot, which I have gladly shared with the concept originator and on other forums. However, since some of the code I have had to write is bizarre and potentially dangerous in the hands of a novice, I seriously considered encryption for certain code modules.

So from my experience encryption helps protect my private code as well as corporate property from thieves, who will either damage the original product or steal the intillectual property for commercial benefit. A real developer who wants to see the proprietary code can usually get a copy under a non-disclosure agreement, they just have to honest about their intent.

Hank Freeman

Senior Systems DBA/Developer Architect

Atlanta, GA