Erik

The "problem" is that SPs are being compared to RVs "with nothing else"

In other words, if an isolated RV cannot do the same as code in a SP, it isn't as good.

In the posted "extra fields" example, I'm not sure the necessary logic belongs in a SP but we can leave that for now... because you certainly can do what is needed using RVs and code. Even with SPs I don't think you can exclude "some" middle tier/client code- eg I assume the user does not get to look at and edit the null values for items that do not need the extra fields...

All this assumes, of course, that there is only one type of item that has extra fields. It is more likely I think that there may be more than one type of extra field.

In which case there will need to be sufficient client logic to recognise the need for extra fields, query, display, and update the relevant extra material. That sort of logic *definitely* does not belong in a SP even if the sql for the different types is in lots of little SPs.

Regards

JR