>Pass-through cursors work totally different than ADO. SPT is a two-tier solution and always returns a Fox cursor. ADO creates an object that holds the data and can be passed from component to component and tier to tier.
Yes - But SPT creates a read data set, ADO is a read data set. In this regard, they would be similar, because any edit changes would require a backend update. ADO and SPT cursors are just the results of the most recent query. Any changes made to the elements of a control they are docked to would require a called procedure to the back-end, to update the 'database'.

>
>Using stored procedures is one way to improve performance.
Agreed, but would passing the stored procedure through an ADO COM (AOD.Rowsource=[execute someSQLProcedure]) be noticibly different from a SQLEXEC(n,[execute someSQLProcedure],[MyCursor]) called from inside a VFP program?

I guess what I saying is: If I write a receipe program for my granny to use on her lap top (and she has a copy of SQL 7), and the receipe program transacts indirectly with SQL SPs through an ADO COM, rather than SQLEXEC(from inside my VFP app), would granny notice any slow down in service. IOW: Why not write ALL vfp C/S apps with an ADO intermediary for SQL calls (rather than reseving ADO connects to IP service. One size fits all.