In a recent post, Jim said something like this (please note that I'm
paraphrasing, and I'm leaving out much of the detail):

"Using SPs to return result sets is essentially an abomination--a
better approach would have been to enhance views."

Then I kinda said (now I might be adding some stuff in...):

"But... I *like* stored procedures. I like that I have 'programmatic'
control over a returned result set. I like that I can use one
language
for generating a complex report, and the return to use the same
language for updating my tables. I like that SPs allow me to work
around flaws in the optimizer... [etc]"

The Jim kinda said, (according to my interpretation):

"The implementation of SPs, especially wrt support of *both* execute
style procedures and result set procedures is a bit of a jumbled
mess.
It is not elegant, it is not clean, and in order to clean it up,
views
should take over the role of select-procedures."

While I might not be very clear in my paraphrasing above, we already
had this conversation a while ago, so you can always refer back to it.

Jim also indicated that he did not disagree "in concept" with what
select-procedures achieve. What got lost on me, though, was this:

Right now a view is essentially a "saved" SQL-select statement.

When you speak of views in the context of a "new" view, what do you
have in mind? Would the "new" view incorporate the flexibility of the
"old" SP?


Thanks,

Greg