Jim,

Good response.

Let me try to argue with some of yoru points.

>1) Security:
> Size is of no relevance here. Security includes more than security of the
>data after a "catastrophe", like just keeping prying eyes off the stuff and
>generally limiting who can actually see the information, even outside of the
>'native' creating product.

Fox has never had security features, adn regardless of what MS decides to do with VFP they will never decide to make it compete with another one of their products as it does now with many. Any hope for seeing security features added to the native Fox data engine is blind hope that is highly unlikely to ever occur.

>2) Size greater than 2 gig.
> While it is generally the case that 2 gigs is ample for small/medium
>business, my most significant prior app (FPD 2.x) was made up of 36+ gigs of
>data. The company was less than 300 staff, 250+ of the "connected" and using
>the system. The customer database alone was approx. 10 gig. It would have been
>far easier/faster to maintain if there had been the ability to store it as one
>table. I guess the good old Chunnel project serves as another example.

There 2 GB file size limit is burried deep into the VFP engine. It affects the way record and file locks are handled and many other things related to teh data engine. It would require, essentially, a complete rewrite of the internals of VFP. I don't forsee MS undertaking a complete rewrite of VFP.

>3) SQL full support
> FP then VFP was continuously improving SQL capabilities, version to version.
>This is what I'd like to see continued. My concern is that, as mid-tier, there
>really is no need for more sophistication of SQL within VFP, so here again the
>developer toiling to deliver a comprehensive VFP solution to his customer is
>disadvantaged in the longer term.

If VFP is to be a solid tool for building middle tier objects it MUST be conversant in the SQL of the backends, it must be extremely good at getting data from the back and supplying data to the front. To me, this seems like a very good reason to improve on teh SQL capabilities. But, at the same time, MS is developing ADO which negates the requirement of any tool to have heavy SQL features as the ADO will handle the SQL requirements.