Thanks.
Appreciate your good work.

It’s possible to take advantage of SQL Server’s query optimizer without using stored procedures. You can achieve many of the same benefits by using sp_executesql to execute T-SQL statements as if they were stored procedures. These statements will receive fully optimized execution plans and those plans will be cached, allowing for plan re-use, a reduction in memory consumption (ad hoc plans can kill the cache), and a reduction in CPU utilization.

Encrypted stored procedures don’t have cached execution plans. Instead, every time an encrypted procedure runs in SQL Server, SQL Server has to go through the entire rigamarole of building an execution plan again. For infrequently used applications, this isn’t going to produce a noticeable effect. On busy, mission critical systems, encrypting stored procedures has effectively doomed the customer to buying a larger physical server to run SQL Server. With the licensing changes in SQL Server 2012 you can bet your bottom dollar that savvy customers are going to start watching CPU utilization like hawks.

I’m not really sure what code protection you provide. It’s laughably easy to rip the source code out of SQL Server even for an encrypted stored procedure. There are very cheap products on the market to decrypt stored procedures and it’s not terribly difficult to figure out the decryption yourself from a few quick searches with your favorite search engine. Security through obscurity will never be an answer because someone will always figure out a way around it.

Protecting IP is a fallacy. If someone wants your IP, they will get it. Your competitors don’t want your IP because you can take them to court and bury them in legal fees for years. Your customers don’t want to figure out your IP because, if they did, they would have developed it themselves long ago. If you want to protect against modifications, there are many ways to solve that problem. People have already commented about it. Jonathan Kehayias wrote an excellent follow-up piece about the IP protection argument. If you haven’t read it, I suggest that you do.

When you supply a customer with software that they cannot tune or troubleshoot apart from buying a faster server, you’ve done them a disservice. When that server gets slow, their only option will be to spend more money on a larger server. They won’t be able to call you and ask for help, they won’t be able to give back to you and make your product better. Their only recourse will be to spend more money.

As a small company who belives in such methods we develop software using such methods. we use the concept that the inteleigence is in the Data and not in the application. It is like that character Data in star trek. The whole of the logic of our application is in the data (including the SPs etc).

We feel that the big companies will be forced to change to these methods in the future. Not being able to protect our code will give them easy transition to use these methods. We wre not talking about one or two Stored procedures. 100′s of them together who function together to give you a end product as a say a accounting system or booking system

Not having a more rigoureous way to protect our Inetelectual Property is stopping us from mass marketting the product. This may be the reason that software such as Navision etc do not have Stored procedures

TL;DR version: Benchmarks show PostgreSQL 9.1 scaling up to around 45,000 transactions per second with 9.2′s code base edging past the 200,000 TPS mark.