Hi Vlad,

While I take your "warning" to heart that this wish might die if it is not aimed at an OLEDB style solution, I guess that I have two reactions to this:

1) If the VFP Team can come up with an implementation that uses OLEDB yet let the developer continue to use all xBase/VFP-SQL commands against 'server'-resident data (processed on that 'server'), then I have no problem at all;
2) It is the extension (of reach, to 'server'(s) and their VFP tables) of native VFP data commands that is the focus of this wish. If this wish dies because of this, then (very sadly, of course) so be it. Someone else can open another wish and I can comment on that one.

I appreciate the comments though.
Jim Nelson

>Hi!
>
>Jim, from what I know, MS use and push OLEDB as a new technology that MS going to use in all database programming and other data accessing. I guess you require to rework this idea to fit it into the idea of the OLEDB, otherwise it have no chanse to survive. I would say it would be good to do something another - built into the VFP functionality of the OLE DB so it will work more quickly than through COM interface, as well as VFP will have built-in OLEDB driver for VFP database that will connect to VFP server, as well as a built-in ability to convert OLEDB record source to pure VFP cursor and vise versa with ability to udate data from the cursor converted into OLEDB record source. OR, at least, MAKE FILNALLE converting of ADO<->VFP Cursor as good as possible with support of all field types (include General) and built into the ADO this functionality to do not use VFPCOM.DLL
>
SNIP