• I think you have the wrong perspective here. My company has been encrypting all of their stored procs since the beginning. I am talking hundreds of stored procs. Some are your normal Crud procs, but I would guess about half are very complex procs that are core to the engine that makes our software do what it is suppose to.

    Here is the rub. We have good intentioned DBA's, that want to figure things out themselves, that really have no business messing around with a system they know nothing about. Nor do they understand how it should work. So encryption just makes it that much harder for them to mess around. It isn't' that a DBA couldn't crack the encryption, because they could. It is just that since the code is encrypted it is just too much work to bother with, so the DBA moves on to other things that need to be done.

    I think you have missed the real reason encryption bothers you and everyone else. It drives you nuts that you can't easily see some code. Honestly I think it is just prideful to assume you should be able to see something you really don't need to be messing with.

    Your issue about not knowing which proc someone is running one, sounds like a source control issue not an encryption issue.

    So for us encryption serves three purposes:

    First make it hard enough so DBA's spend their time on something else other than looking at our code. Trust me you don't want to look at it, it is really complicated. It would just give you a headache, like you need another one of those.

    Second to help us support our clients better. When our clients have a problem or a bug it isn't going to be because they were messing around with stored procs. We have to support them it would be a nightmare if we couldn't trust the db code was unchanged. I know you say just charge them more, but honestly have you ever had to trouble shoot a super complicated system? It is bad enough when you know the code you are starting with, it is much worse when someone messed around with something they don't understand and now expect you to fix it.

    Finally, we do want to protect our product. Honestly even if we didn't encrypt our code it would be hard to duplicate what we do. If you don't know or understand the original business rules it is hard to make sense of the code. Still encryption isn't foolproof, but it does make it that much harder.

    Anyway, I would suggest you hold your judgement on sql encryption until you have worked with it and seen the benefits first hand. It makes a difference at my company.

    Ben