>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
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only