Jim,

<snip>
>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???

Security, tables larger than 2GB, and SQL full support are all very good reasons to use a database server. I can't reconcile how a business that requires tables greater than 2GB is not a candidate for a C/S solution.

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

I don't agree that following the goal of making VFP a better player in COM and DCOM is any kind of indication that any other part of the product would be ignored. In the case of ActiveX stuff, quite the opposite is true.

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

The internals of ADO are the Fox cursor engine. VFP is an ISAM database, and ISAM is supported by ADO, as a matter of fact, ADO supports all databases that have ODBC available.