Charlie

>>(1) Ya can't change the SQL property without first dropping, rebuilding, then adding VIEW back to database. Parameterized Views offer a little help, but doesn't come near the the flexibility of SPT cursors in this regard.<<

I'm a bit frustrated because you are now referring to SPT rather than SP.

Of course a SPT is more flexible than a predefined RV. It also takes a great deal more work to do all the things a RV does.

>>(2) Gotta store connection handle in a database. I pefer the flexibility of SQLSTRINGCONNECT() and ya don't need a DSN on the client.<<

No, you do not have to store a connection in a database to use a RV. That you prefer the "flexibility" of sqlstringconnect() is your preference, bearing in mind that you have said you have not tried to develop with RVs.

>>(3) View designer sucks.

Agreed. but you do not have to use the View Designer for RVs any more than you have to for SPT. We do all our views in code. Had Eview been available in 1995, we might be using that.

>>(4) Views can break when underlying table changes. <<

Agreed. But so can SPs.

>>You don't have to do it that way. When designing my data classes, I felt that any gains to be realized from minimizing your parameter list on an update would be offset by the additional overhead of checking for changes. I could easily add that in if I thought it was worthwhile.<<

Then you'd need to write and maintain dozens or hundreds of lines of SP code to manage the partial parameter list. All this for "easier" maintenance and/or performance.

>>My data classes have built-in conflict resolution. If someone commits a change while you were editing, your gonna know about it.<<

That's my point. As a busy theatre surgeon I don't want to know about it. I want to enter whatever part interests me and have it just save without being asked whether to overwrite what the anaesthetist or nurse entered into different fields at the same time. With RVs, that is all there with no extra effort.

Regards

JR