ADO does work OK with VFP. The only issue is that "returning" an ADO recordset usually involves passing back a pointer, which creates a stateful object taht must remain in scope (see ASP, using server-side caching for data instead of RDS). Even though MS handles the persistence and threading issues OK, this methodology doesn't lend itself to even moderate size result sets.

MS answer is RDS, which you are already investigating it seems. RDS is a client-side cache of the data. But RDS doesn't seem mature yet.

At one point MS was making vague promises about being able to pass ADO recordsets to VFP cursors and back. This would have made ADO a much more compelling approach.

>>3) Pick a different transport mechanism. You can convert result sets to primitives (like strings), a la SDF files or XML, and reconstitute them into cursors from the client. XML works exceptionally well for this. Ken Levy's got a dbftoxml utility on his Web site that works pretty well (www.classx.com). With XML you have the added advantage of letting any client that works with XML read the result set. Eventually (hopefully) ADO will start to work this way with VFP too.
>
>Eric,
>PMFJI, but I was wondering why you say that ADO will start to work this way with VFP too? The reason I ask, is that I'm just starting to work with COM objects in VFP and thought of using ADO recordset for passing data. I've seen warnings agains using numeric fields with ADO, and right now I've got a problem with including a memo field in a select with RDS, but the basic functionality seems to be in place?
>So, I'm wondering if there is something in particular you are referring to? There aren't too many references about using ADO/RDS with VFP, so it's quite a lot of reading and testing to get the hang of this...
>
>Arne