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