John,

With "help" like this on the issue, we'll likely never see this type of functionality in VFP!

Rather than accepting excuses or "strategic direction" arguments or even 'survival of VFP within MS' logic, what's wrong with this idea???

So it doesn't "fit" with (apparent) MS direction - so what??? WHO sets the direction??? Us users deserve at least a significant say in those matters!

You can clutter my mind (and my systems) with ADO and COM and SQL-Server and all manner of other stuff to achieve some KLUDGE to an end, or you can go straight to the end. What's wrong with giving US (the development community) that choice???

We have a VFP Automation server capability but it won't let us do *naturally* what VFP does best - access the data we need (and give it back to us in the customary manner). Yes, we can get at data, but it has to be done through parameter lists, usually with parsing of some string containing field information. Try to pass a record set that way.

I understand that something called ADO takes me some distance along this path. But I also understand not all the way! What's wrong with having VFP do this??

Sure, it might result in a few less SQL-Server sales. But it might also result in a few less brand-x SQL sales too, not to mention many many more VFP sales. Not to mention the impact on availability and RELIABILITY such a facility would let us deliver ( store data on a protected server and no index problems when users suddenly pull plug or lose power.

When all is said and done we need a way for MS to listen to the development community at large, and not just to their OWN objectives or the objectives of a few "connected" people who have specific problems needing resolution rather than more typical problems with the language and the development environment.

Regards,

Jim N

)>>Thanks for that. I'm really looking for native VFP functionality though. I >could do what I want with ODBC too (I believe) but I want the efficiency and >power of VFP-to-VFP and not some other gunk.
>
>Jim, you mentioned Automation Servers. Once you do that, you are really getting outside of the VFP realm. Yes, you can create automation servers in VFP - but you are now getting into the world of COM. I demo'd at Devcon how VFP automation severs can interface with ADO and RDS to serve up data to a variety of clients: Excel, VB, and VFP itself. The fact that VFP can do this now is a big deal. If you want native VFP functionality - its there - always has been. If you wan't to get into automation servers, then you are going to have to start using things that are not in VFP box. Then again, ADO will be in the VFP box. Its also important to note that ADO is based on the VFP engine.
>
>< JVP >