>>I take it that you completely discount the possibility of developing an application using C?
>
>Hi Ed,
>
>OK, I'll bite... yes, I discount that possibility. If for nothing else, only because my clients would gain no advantage from it. I don't see any reason to do so. I could stretch your point and mention assembler.
>

I think you've missed the point; it's not VFP vs VB or VFP vs C, it's VFP with a non-supported native file system vs development with ADO and the ability to use both data and the basic manipulation models developed using ADO regardless of the language platform used to write the app. ADO scales, mixes languages and offers many deployment models independent of language. You can swap languages, and the ADO behavior remains the same regardless of the language used to implement it. You can swap backend, and ADO still works the same regardless of the change in backend platform.

The decision is whether there's sufficient justification for VFP and reliance on the non-portable native file system behavior to elect to use it rather than ADO as a data engine grafted onto another platform that doesn't offer an integrated native data engine. DO the xBase-derived language constructs make a sufficiently strong argument not to develop using the ADO data model? YMMV, but I find less and less inherent advantage to using VFP for new projects where I anticipate the need for deploying to environments where I know that I'm going to end up not taking advantage of the native file system for any of dozens of reasons. VFP is not a dead product, but there are a tremendous number of new development opportunities where considering the eventual goal for the application indicates that I'll have to expend far more effort to work around VFP's deficiencies than the early advantages that VFP may offer.