Josh,

Thanks for the reply. I had to write a paper on this and I did make use of ADO for the cursor returned to a calling application. The COM Server would be written in VFP. The native app is VFP and it looks as if we'll keep two versions of this "middle" data piece. One will be the classes which will be included in the project and another with these classes broken out as a DLL which will return an ADO rather than a native Fox cursor.

I was at MS yesterday looking for papers regarding this topic and didn't find much. Or at least my searches didn't, I'm sure some good stuff exists. As for ADO, I think someone here said that V 2.0 is obtained by downloading the current public beta of InterDev. I only saw 1.5 available in the ADO section.

Steve

>Steve,
>
>If you create a dll you'll be able to access it from just about any front end. The tricky part is getting the data back to the front end (even getting the data from a VFP COM server to a VFP front-end can't be done gracefully with straight VFP). ADO seems to be the best solution. FoxPro doesn't work great with ADO, but you can make it work. VB works great with ADO. You'll want to get your hands on ADO 2.0. It will come with the next version of Visual Studio. You may be able to get it now from the web, I'm not sure.
>
>>Here's the situation. The main app is written in VFP 5.0 and it currently only accesses a native VFP database. This front-end was designed to not care where the data comes from. We are now in the process of building the middle ware piece to get the data for the front-end. This work has proceeded using Andy Kramek's Dec '97 Advisor artile as a guide. The issue has come up that it would be nice for VB or C++ apps to be able to also utilize this middleware piece to access the data.....regardless of where it is. This implies the use of a DLL. We'd only like to develop/maintain one middle piece that our VFP app or anyone's app could use to display data with.
>>
>>Any thoughts and suggestions would be greatly appreciated.
>>
>>Steve