>Hugo,
>
>It does seem that dynamic SP would share the same characteristics as dynamic SPT, in which case you'd have to ask "why are you doing this?" (And I suppose you might expect an answer like "because SP is always best") ;-)
>
>Re RVs: they're not better than SP or SPT, they're just a different approach, with different advantages and disadvantages. I don't think I'd consider a RV for the example in this thread- unless it has to work on multiple backends, in which case a caching/munging tier might be the way to go, using plain SPT or gendbc to convert between databases. The arguments to which you refer tended to be the opposite direction- generally "SP is always best" or "RVs don't scale/are insecure" etc etc.

Adding a tier is the solution to many problems. No printer has all possible printer drivers. Windows does not have a massive database of all possible printers. What worked is to give Windows the ability to have pluggable drivers.

I still firmly believe doing SP only is a decision based on fear and incorrect information - despite the fact that lots of people do it. People fear SQL Injection and think dynamic SQL permits SQL Injection and that SPs magically prevent it. There are also those who think that SPs only is the best way for performance, when many of these build improper SPs or build SQL within these SPs that do not perform well.

I can see that every application having copies of queries would be inefficient for a large organization.

So what's a client/server - database equivalent of the pluggable printer driver? Is it ORM? http://en.wikipedia.org/wiki/Object-relational_mapping