>>Everything you describe here could be done already... You may have to write your own metadata layer, but I feel certain you could do it...
>>
>>What do you think most people want?
>>
>>1. Improve the X-base'ness of the product
>>2. Improve the integration with ADO/OLE-DB, SQL-Server, etc....
>>
>>My guess is that most folks would vote for #2...
>>
>
>Obviously count me for #2 - an extreme 2, who'd like to see 3 - a reduction of xBASE behavioral support.
>
>>Jim Booth's observation is particularly good. In what you are advocating here, you would be making the migration to SQL-Server, Oracle, etc that much more difficult.
>>
>>As far as the conclusions you have reached regarding SQL in general, you know my stance on that....<s>....
>
>I'd like to see VFP move into a marketplace where we give up backwards compatibility, strengthen the ActiveX/COM capabilities, and retain it as a strong interpretive language with the advantages of compile-on-the-fly, macro-expansion, name substitution and expression evaluation. A fast, powerful and flexible interpreter with strong data handling, that plays well in the COM environment definitely has a place in Microsoft's product lineup well into the future.

Hi Ed,

It is not my area of expertise, but I wonder if VFP stuff providing backward compatibility could be technically separated from newer and better version of VFP and added to the package as separate DLL, so if somebody wanted the backward compatibility then s/he could add this DLL to the project?