Kelly, I completely agree that the model you describe is an excellent way to deal with SPs.

I regard the parameterized nature of SPs as an inherent difficulty. Example: say I have a table with 202 fields and a SP to update those fields. Unless I want to create a stable of SPs to update field subsets with code everywhere to manage them all, the SP needs a parameter for each value that might need update- say 200 parameters.

If (as per usual) only a field or two is changed at a time- e.g. a married/unmarried bitfield is changed- then use of a SP with 200 parameters is getting inefficient, especially if one does not want to send back all the field values just because one has changed, or to update the database with all 200 fields just because a bitfield changed. Bring on the code!

The above seems an extreme form of the same scenario that makes overloading so compelling. I guess I am curious that people who promote use of overloading for the usual reasons, seem perfectly happy to tolerate the same scenarios involved with using a SP which they also promote.

I could now observe that the above data issues are trivial for those who include remote views or cursoradapters in their arsenal, but that might seem provocative ;-)

Regards

j.R