snippage
>
>Please. If people stick to Win16, then they're stuck with Win16 development
>tools. Why should MS waste money on a dead platform that is never going
>to bring a return on investment. If you run Win16 - use Fox 2.6 - it works
>well in that environment.
>
>As to low end markets - I don't understand that debate either. Just
>because VFP is aimed at middle tier by MS doesn't mean you can't build
>quality single user or network applications with VFP. I do it all the
>time, both for personal use and for use by other small businesses.
>The point there is that the feature enhancements on the high end always
>always also benefit the low end, even though that point is never pushed.
>
>+++ Rick ---

Rick,

I'm with you regarding those who stick with 16-bit. I was *trying* to say that there are far more than THOSE - namely tons of small/medium businesses who don't want/need SQL Server or it's ilk.

And sure, lots of good apps can be written using VFP as it is today. But what of the improvements people want/need, particularly in the UI capabilities, the table capabilities (security of some kind, larger than 2-gig, advancements to VFP SQL capabilities, etc), standardization of UI objects as "Windows" compliant, acceptance of *any* ActiveX, etc. etc. etc ad naseum???

We *cannot* expect much in any of these areas with the declared direction. In fact we can almost expect ignoring of bugs in existing UI/table/database components already extant. This can hardly be called a tool which one would want to bank one's future on, ASSUMING development as you state. It would get awfully frustrating in short order.

As far as using ADO is concerned. . . we're back to the renowned VFP **SPEED**, which I seriously doubt is delivered with ADO. And, by the way, does ADO really support VFP tables and databases. I know I got the possible hint that VFP was considered "VSAM" and that VSAM was at best superficially supported in ADO.

Regards,


JIM N