>As ADO becomes a standard, its inclusion in VFP is therefore critical if we >are not to be further marginalised.

>IMHO we need to scream the house down so that ADO is better integrated in VFP. >Had it been in this release, we could have begun using it more confidently and >smoothed the path to (dare I say it) the language we eventually migrate to.

If you want to scream - thats fine. However, the VFP team basically knows what is needed to get ADO better integrated into VFP. Specfically, there are three things:

1. ActiveX Data Binding
2. The ability to raise events in middle tier components
3. Seamless interface between VFP Cursors and ADO Recordsets

On a broader level, better ActiveX Support for VFP is also required.

FWIW, this is a priority for the VFP team. They have heard us load and clear on this one.


>Yes, ADO is in VFP6... but that ADO cannot be used natively for VFP grids >paralyses its sensible use in many apps. Apparently Ken Levy, yet again(!) has >come to the rescue with a class that will do conversions for us. I have not >seen it but my prejudice leads me to believe that converting to/from ADO using >VFP code will carry a performance hit.

Yes, there is a hit. Then again, ADO and the VFP interface are not a real good mix. A VB or IE front-end along with a VFP middle tier on the other hand, is a good mix. Also, if you need to serve data up to another application, ADO is a good fit there.

On the other hand, if you only have 10-50 records at a time, on a decent machine, the performance hit of converting to and from a VFP cursor is somewhat insignificant.

>IMHO we need to make it very clear that not having basic ADO features like >flexigrids is a major issue.

Its already clear and the team has rec'd the message. My SRO sessions at Devcon I think signalled to both MS and Advisor how popular ADO is. After all, it fulfills one of our requests - an objectified way of dealing with data.

>Actually it is an old issue, with VFP never having had the power to manage >multiple data binds with any ActiveX, and it is most disapointing that it is >not fixed this release. Why not? One might also wonder why the VFP beta >concluded so early when VB and VJ are still deep in beta and VS shipping has >been delayed until September.

What makes you beleive VB and VJ are deep in beta? FWIW, there have been tech previews of VJ available for a while. Take my word for it, if a September release date has been announced, no product is deep in beta at this point. I will leave it that.

>As for ADO itself: I have to be careful what I say :-) but one could be >excused for comparing it to C/S in FP2.6. Programatic management and field-by->field manipulation is the order of the day. Yuk. :-)

Not if you use a different UI.

>In the end, those who have made the move to parameterised views are very well >prepared for ADO.

I somewhat disagree here. Rather, those who have relied on SPT are better prepared.

>Elimination of indexed seek/scans etc and replacement by Views is an excellent >discipline.

Not sure I understand this comment.....

>Do we need to fear ADO?

>As a new concept or standard, no.

>As something only partly implemented in VFP, yes.
>
>Do we need ADO?
>
>Some needs have been identified- transferring cursors to COM and other apps, >for example- and these are real needs for those who remain in the Windows >camp, who will be using COM more and more. I know some will ask "why do we >need COM now when we never did before" and the answer is that breaking >monolithic apps into COM objects offers significant performance, scalability, >distribution and reliability advantages that we *should* be harnessing for our >clients.

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


>To sum up: My advice to VFP people is: look at ADO, learn a bit of it. It >isn't so hard- most of it is perfectly obvious to VFP developers and really >needs no explanation at all.

I think that is a sweeping and somewhat inaccurate conclusion. For you it may be accurate. ADO is a very different way of dealing with data and compared to native data access in VFP, is and will be a challenge for many folks to ramp up to.

>My opinion? Well, after using other tools and ADO for over a year, I'm still >here. :-) Yes I have looked at other tools and yes my company has moved much >of our work out of VFP... but into Java, not VB. If you want to use ADO, COM >and so forth, I strongly suggest you look at VJ or something like Supercede >that you can download free at supercede.com.

Please state why you would suggest VFP folks look at VJ over VB. Not that I disagree or agree with your statement here. I am just curious was to why you have made that conclusion.