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

Nobody will argue these points, but the focus of discussion was shifted tremendously (or purposedly). The point was that in some situations XBase approach provides better performance, nothing more and nothing else. If some approach happened to be called 'XBASE' it does not mean yet, that it's bad.