Recently I was going through the buy or build process on a small segment of functionality needed for a project, and ran across something that looked like it would work, price point was realistic, and when I looked at the source they made available was thrilled to find it used stored procedures. Skipping over some interim steps, the final product that was for sale did not have stored procedures. When I inquired about that, the decision was made to simplify use of it for their customers. Now this is C# ASPX code and requires a database to support it, so I wouldn't call it something a novice is likely to buy or install.  A better reason - though not one I subcribe to - would be to remove the procs to make the data access code more generic, enabling use of Access, MySQL, and other products. I can understand the allure of write once and use on many platforms, though you wind up with a lowest common denominator solution.

So in theory (my theory that is) you're selling code to someone that understands C#, web sites, and at least how to get a SQL Server database up and running and how to run a few scripts against it. Does adding stored procedure really increase the complexity, or it only perceived complexity? It is complexity during the install, or more likely, when they need to change/extend the code (which is why they bought it, or so I'd think).

We're back to a subject that confounds me; I swear developers don't like data access! How can developers that get abstraction and indirection not understand the relatively simple concept of using a stored procedure as packaging and the associated gains? Or even if they don't like it, surely it's not a hard concept to follow/amend if needed?

More on this on another day, for now - consider, are we doing our part to make our technology approachable?