Charlie,

>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.
>
>Since you can not subclass a ADO recordset to customize its behavoirs, you can not build these kindds of frameworks around ADO. This is way I think ADO is inferior to VFP in terms of data access.

I don't how exactly your framework would be doing and how extent you want it to be flexible. But I wanted to say that majority of my data manipulation codes and connections that uses ADO are in the form of COM DLL classes, how would it be that it can not be subclass? In fact, JVP confirms it that ADO is better when it comes to SP calling.