>
>Let's see, the other option is no view designer at all.
>

Yes, or add a system variable _FixItYourself ;)

>To those of us who are familiar with vfp and know about its quirks and idiosyncracies, this is just a personal preferences issue. I use the designer for single-table views and the command window and eView for more complex stuff.
>
>It has become second nature to me by now.
>

We have no choice, but work around these limitations. But if you've ever used another designer that works and allows you to modify a view/query either graphically or by changing the SQL code, then it's quite hard to accept these limitations.

>HOWEVER, when it come to trying to get NEW VFP users, this becomes a rather serious issue. The designer's unreliability makes vfp as a whole, unreliable to a new user (I can picture him or her [wrongly] wondering "hmmmm... this product is not really ready for the real world").
>
>I know many of you throw the designer's problem in the same bag as the report designer, but they're radically different problems: the designer is UNRELIABLE, which is unacceptable for a new user. The report writer, otoh, is LIMITED, which is something that anyone with an IQ greater than his shoe size would understand and expect work-arounds for.
>
>There was a thread sometime ago about how the marketing people (referring to Ken Levy at the time) had nothing to do with bugs. Well, I think we just found one bug that would be very important to fix as it's detrimental to the marketing team's efforts.
>
>Ken, if you're reading this, I think that in vfp 8, the VD should either be fixed COMPLETELY, neutered so it allows only one table per view (thus avoiding reliability issues altogether), or replaced with thorough documentation on how to create views as well as pointers to Erick and Steve's products.
>
>Alex

This is a very good point. Limitation is one thing but breaking something that works is a whole other issue. The fact that you can break a working view simply by opening it with the standard VFP view designer is unacceptable.

I really believe that this can't be such a big issue for the VFP team to fix. It's not like asking for OOP reports or menus. This kind of designer works much better in *any* other MS app and since most of it is dealing with standard SQL code it should be quite easy to port this functionality to VFP IMHO.