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

>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!

Man, you need to wake up and see that VFP is hardly a high priority item
at MS. At this point it's becoming increasingly important that VFP can
take advantage of Windows system services. If Windows provides functionality
that's not native you can bet MS will not waste time implementing it inside
of VFP. This is important not just to satisfy the MS marketing machine, but
also for developers who gain by aquiring more mainstream skills that apply
to more than VFP. It's time to step outside of the single box development
environment!

Which is as it should be.

I for one think it's important that people start thinking about technologies
like ADO, because it is the future of how things will work. Would you rather
keep working into obscurity, or use tools that embrace some forward thinking
and future skills that you can apply in more than VFP?

Whether you like it or not COM and ADO and VStudio is the future for VFP.
You can whine all you want, but there's no going back. Support for these
technologies is what is and will keep this product alive.

>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???

You have a choice. Use what's there and don't complain when you *don't* get
your features that are available by the system.

>>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.

You're not listening. John just gave a valid example of how you can sidestep
that issue and you can do this today with VFP5.

>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??

But *it is VFP* that's the whole point!!!

>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.

You get no argument from me there, but you have to remember that things
get prioritized. I can guess at what you're wish list looks like - most
of us have at some point made those requests. Some of them are realistic
others are not. Some of these issues will be resolved externally to VFP
at eiterh the system level or through Visual Studio integration.


+++ Rick ---