Mike,

----- much snipped
>
>Again, I'd personally love to see this feature, and an objectified DBC as well, but I really think a bigger deal is being made out of this issue than is necessary. There are solutions available to this problem now, I'd prefer that MS focuses on the things we can't do.
--- end snip

There is *much* that VFP can't do (Menachem is fond of bringing up word-processing and spreadsheets all the time) and should never do.

There is much that VFP doesn't do but should do. Just because some of these things (that it doesn't do but should) *can* be done by other products is no legitimate reason to withhold it from VFP.
Let's look at this from the other end - WHY do we have Access at all?? MS bought FP *before* Access hit the market. Yet we have Access. And Access keeps getting enhancements, and is not in jeopardy within MS Explain that.

SQL Server (or any other SQL facility) is *not* a cheap proposition. Aside from the basic bucks it costs to equip a shop with SQL Server, there is also the costs of learning, maintaining, upgrading, etc. Not to mention the added complexity of it all (and SQL Server justifies its cost based on its complexity too).

So this idea that we needn't pursue things when other options are available really doesn't hold too much water. There are a number of things that we (the developers of end-user applications) *need* in the product, and we need them in THIS product (VFP) because that is the major tool we sell our services with. And because our clients do not want to buy half of MS (or the PC world) when they buy our solutions.
There is PLENTY of room for LOTS more features in VFP. There is even room for deliberation as to the extent of those features.
What is absolutely missing is some mechanism for such discussion and agreement and follow-up and follow-through. MS remains mute on this, and now that VFP is "mature" it is time for them to revise this.

Finally, the major features of VFP are speed and flexibility. If we accept the MS "vision", then we are headed to SQL-Server for the data store. That kills both the speed and flexibility aspects! What's left. . .OOP? And what's to stop MS from coming out with some 'converter' which takes VFP code and converts it to VB7 or VB8. Yes, take comfort in the fact that VB isn't OOP. But some here have suggested that VB can have 'inheritance by copy-and-paste'. Now that is something that a "converter" can do real quick.

We need to focus on VFP and making it better all-around. We (the developers making end-user apps) need to set the agenda for future VFP development. We are the customers here, and MS would do well to remember that.

Cheers,

Jim N