>Yes, but what a shame it isn't in the new release. The ActiveX issue has been >around since August 1995, after all, and they must have "heard it loud and >clear" a few times since then. As my grandpa used to say, "a man who's full of >words not deeds, is like a garden full of weeds." And we know what happens to >gardens full of weeds. ;-)

It is a shame we did not get it this time around. Once again, the priorities were in the middle tier. Not that I agree with that... it just the way things are. I also don't think the VFP folks to what extent the dev. community would gravitate to ADO.


>May I ask you to expand on this statement? I only ask because in my intranet >apps being hit repeatedly by busy doctors, "somewhat" insignificant may become >a "last straw"... especially since ADO is already so obviously slow compared >to VFP5 with foxisapi and a Java frontend...

Internet apps are a completely different issue. I can't see converting ADO recordsets to VFP cursors practical at all in an Internet app. My comments where in the context of being outside the internet/web.

Yes, ADO will be slower than VFP - you won't get an argument from me. However, once you do stuff across a WAN or need a C/S architecture, ADO will smoke VFP as VFP is file/server based.

>So you have said. Politicians often "hear the message" as well.

Would it help to say that I have actually sat down with members of the team??

>Yes, and in my company's reviews of that tech preview it seemed riddled with >user interface and implementation issues. To us it seems to be still a very >"beta" product.

OK, I see your point here.

>God help us, then. 8-)

I don't disagree with you here<g>.


>Yes. Again, a significant comparison issue for VFP people. For us, like going >back to pre-2.6a C/S. For others... something better.

Other UI's IMO, like IE/DHTML and VB show a lot of promise. These are tools that can be used today - without us having to wait for things to get implemented in VFP.


>>Another need is accessing data via HTTP.
>>RDS, a part of ADO does this rather well.

>Native VFP does it faster for things like images. Eg: if you prefix blobs with >HTTP1.1 "content type=xxx/n/n", VFP allows blazingly fast display of MIME->compliant images from a database. Faster than ADO in our tests.

Have you used RDS? Working with images is nice, but what about data???


>Err... well, I didn't actually say that, did I?

Yes, you encouraged folks to look at VJ and a Supercede