There have been a few postings about this deficiency in the CursorAdapter implementation, and again I want to check and see if there is a workaround. I personally think that the CursorAdapter is much less useful than it could and should be because MSFT made it a one-way technology. What I need is a way to quickly convert a VFP cursor to an ADO recordset (the CursorToRS functionality). I see this as a critical step in leveraging the power of VFP within an MTDLL for web/ASP applications. Basically I need to do a complex series of VFP queries within a single call to an MTDLL and quickly convert the final VFP cursor into an ADO recordset, and then pass the recordset object back to my ASP application. This capability is key to maintaining a separate and independent data manipulation layer in the application. Yes, I know that in the final step of my processing I can pump out a uniquely-named VFP table to disk and then use the VFP ODBC/OLEDB driver and ADO to do a "SELECT *" from it, but that seems very inefficient. Any suggestions on how to solve this problem?