>Walter,
>
>I understand your observation, however (you knew there would be a however didn't you :-))

I did know you would jump in, yes.

>The problem I see with it is this. As it is now VFP's SQL is not directly comaprable to any other SQL implementation adn that causes some design problem when moving an app from local data to client/server data.

Which ones ?

The problems and confusion that is already present with regards to VFP's filtered cursor is enough for me to not want another proprietary optimization emthod for queries in VFP.

The distinction is made in design time, and not dependend of any existing indexes, so problems like the filtered cursor (indeed this feature is related to what I want) would probably not occur here.

>I can do what you are describing right now by writing my own set relations and so forth or I can choose to implement using SQL.

>Having SQL create an xBase environment just doesn't seem like an area of the rpoduct that I would like to see the developers spending their time

I'm not sure what you're saying here Jim,

I've ran another series of tests here and I come to the conclusion that performance gains can be HUGE to even a factor hundred. With the test described in the thread 'Differences between xBase and SQL implementations' i've managed to see differences where the performance gain was more 1700% native: 1.2 sec against about 21 sec SQL.

What you can't do with your solution is use this 'view' in a SQL command because it actually exist out of more tables. When VFP can hide the implementation of it, you'll create a VFP view with one alias where all (except for a few) DML operations should work on.

I think of this construction as an implementation of some part of the relational model, which is implemented wrong (IMO) within SQL. The actual goal behind this reasoning is to get VFP more towards the Relational model.

Regards,

Walter,