>Jess:
>
>>>I use ADO/SP when it comes to manipulating data
>
>My C\S framework works entirely on SP's. I wanted to build a reusable data access framework that would enabled me to interface with SQL Server via SP's. To do this, I created special cursor and DE classes that encapulsuate all the behavoirs a cursor would need, like determining what SP to call based on the type of update, what parms to pass in to the SP, how to handle update conflicts, saving, deleting, editing etc. Now when I derive a new cursor, the only thing I add are the validation rules unique to that cursor. This is a real data driven approach.
>

I'm working on something like this now (with lots of SP's); I am just not basing my data classes on the cursor class. I am using custom class...at this point :)

>Since you can not subclass a ADO recordset to customize its behavoirs, you can not build these kindds of frameworks around ADO.
>

I don't think this is a true statement, although I cannot disprove your statement at this time. I'm fairly early in my process, and I still might come to your conclusions.

When you say 'ADO', I think you must specifically be referring to ADO recordsets. I don't see any reason why ADO is not flexible enough to do what you are describing with SQL Server SP's, and to populate local cursors by pulling down recordsets. It seems the whole process can be generalized, with subclasses to handle business rules, validation, etc. I'm not proposing that any updates would be done through recordsets at all.