>--- snip
>>
>>Who are the masses, Jim. Do I count as one of the masses? What about Jim B and John P. Do they count? We all have a different opinion. I know that MS, for a fact, *does* listen to user requests. Just because I didn't get all my requests doesn't mean I wasn't listened to.
>
>Well, in my review of the "Wish List" here on UT I couldn't count 3 items which were noted as implemented in VFP 6 in reports to date. That list was representative of "the masses" for me.

OK. I'll buy that. I did not see that list so I cannot comment on it. fair 'nuf.

>>
>----- more snipped
>>
>>OK, and you can't do that now? I can think of a way to do that right now. In 5 it would be a bit kludgy. In 6 it is less so. In 6.x, with more ADO improvements, it will be even less so. But you can do it.
>>
>>Jim, what would you like to do (a concrete example) that you can't?
>Here's a summary: I wanted, early into VFP 5. and its touted Automation Server support, to build an app where several (say 20 - 100) VFP client machines would use a VFP "server" to obtain/update data. It was to be 2-tiered, modelled on 3-tier. So I set about finding out how many clients could be supported in such a scheme with REASONABLE response. It came to light that one client would have to complete before another could be handled. This projected out to VERY slow (unuseable) service). Still further, I found that I couldn't pass records/cursors back/forth. So, says I, maybe I can manage arrays. Foiled again - no array support between VFP client/Server. So I gave up. And I wrote a Wish List to MS. And I got a positive response. So i bided my time. I continue to bide.

Jim, I did most of that in FP 2.0 with good response. I can think of several ways to handle this. I will agree that the ideas are somewhat kludgy but if I had to implement something like this for a client, I bet it could be done.

>>
>---- more snipped
>>I hear this. I don't think that expectation is reasonable any more. Software requirements are getting much too complex for that. Would you want MS to include all of Word in VFP (and vice versa?)

>No, of course not. And I'll assume you are deliberately being silly here. I just want a simple and logical extension of VFP. Something quite minor in the overall scheme of things, but with VERY high impact vis-a-vis the future applicability of VFP.

I wasn't being silly but I was making a point. If something should be in VFP, then fine. I get the feeling sometimes that some people are interested in the one stop shop and I don't see it anymore. That's all. We never had it, is my point.

>>>By the way, I looked up ADO in VFP 5.x Help and came up dry. I wonder why???
>>
>>OK, I'll bite. Why?

>Nothing, other than many have said that ADO is supported in VFP 5. I expected to find something in Help if that were the case. *IF* people have been directing me to ADO and I find out that ADO is more 'unofficial' than "official", then I will be most disappointed indeed. Is ADO packaged as a product?? Is ADO sold, or is it supplied to us out of the goodness of MS' heart? If philanthropic, should anyone really be writing production apps using it??? Would I expect to find it within the next Visual Studio release?

ADO is supported in 5 like Excel is supported, I guess. I have not tried ADO in 5.

I do not know how ADO is distributed so I cannot comment on that. My guess is (emphasize the word GUESS) it will come with VS.