>The biggest problem I have with ADO is that you can't subclass a recordset to customize its behavior. OTH, my VFP cursor classes are designed to handle all data access requirements necessary to run SQL Server via stored procedures. They always know what SP to call, what parms to pass, how to deal with update conflicts, ect. They also have places where you can hook in event code, like after update, insert or delete. Best of all, they are infinitely extensible and totally reuseable.

Yup. Sounds similar to my cursor classes. Furthuremore, there is much more flexibility in terms of whether you want to use stored procs or not, thus making it easier to swap backends. I have hooks for everything and have needed to use all of them one time or another. Limiting myself to strict use of stored procs does not sit right with me.

>As for ODBC, never had a problem. Just SQLSTRINGCONNECT() and your off. No DSN to manage. What could be easier?

Never had a problem either.

>Then, when you get the data down to the client you have the VFP cursor engine for manipulating the data. I especially like using set relation for managing relations. In a client server environment you want to minimize the number of trips to the server. Its nice to be able to bring down everything you need at once, then relate the data using set relation. A good example would be an invoice with associated line items. It saves having to make another trip to the server for another child record each time you switch records in the parent.

Well, here is where we differ. In a client server environment you minimize the data brought across the wire.