Hi John,

>You can start with creating the ADO recordset directly with ADO. You can then use VFPCOM to convert THAT ADO Recordset to a VFP cursor if need be.

Thanks, the limitations of the ComUtil is what I am after here.

Currently (this may change), I am doing as you suggest: I am creating ADO recordsets directly from the data. What I am using them for is to move data between COM servers(and from tier to tier).

My concern is when I need to unpackage - repackage for VFP. The data always go straight to an ADO RS from the data source (SQL Server in this example). On the way in from the client, it gets packed into a fabricated ADO RS for the journey to the Data Source. If I want to leverage VFP in the middle, I need a reliable way to package and unpackage the ADO RS's.

Currently the CursorToRS and RSToCursor seems to be working--but then I am not using anything but character fields, and CAST()ing the data into SQL Server.

This is ok for now, but I may need other data types, and I am not sure how scalable all this CursorTORS conversion is. Generally, I do it once (and only if necessary) as the data moves into the COM object, do my stuff, and either HTML out (from the client object) or back into an ADO RS (biz tier)--its here, as I start really doing this unpackaging that I am concerned about VFPCOM's bugs.

XML, as per Dave's suggestion, is looking attractive.

Thanks John,
Bill