Hi:

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.

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

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.

This framework works so well, that my customers where blown away by its performance through an ordinary 56k modem.

Charlie