Most of the work I do here supports "internal" clients. The parts that support external clients is only accessible via web based reports (CE). The work for the internal clients is rarely encrypted. BUT, there have been instances where encryption was warranted. Mostly to protect the end-users from hurting themselves. And by that I mean, garnering the wrath of our team for their experiments.

This was implemented after one very nice, and well meaning accountant saw what I was typing and decided it would be nice to report on income and positions, but didn't join the information correctly. The resulting Cartesian set (20M x 21M) brought our production server to a standstill. (These were fairly wide tables, 350+ columns. They've been reworked in the years since.)

This problem has been mitigated by SQL training classes, and by a more friendly relationship with the departments. Though I still have the reputation as a hostile, petulant @rsehole, my coworkers actually come over occasionally to say hello and ask a question such as "how do I...". They've come up with a nickname that I actually like... I'm Mister Black & White. This came about during a meeting in which I took the position that X is either right or wrong. "Like being pregnant or dead, either you are, or you aren't."

I agree with the previous posts, for the most part it is unnecessary, but there exist specific circumstances where it is desirable. Not so much to stop a hacker, but to stop the well intentioned coworker. I guess this is analogous to the dead bolt on my doors, they'll slow the intruder. But a determined hacker/intruder can circumvent the protection.

Best wishes for Passover, Good Friday, NichLactemyer, or whatever holiday it is that you celebrate or not...