Erik,

>Walter, I have not read the entire thread, but I saw the thread map, and judging by the names you have been discussing this with, I'm guessing that I will not be the first to disagree.

Nope, you are not, so welcome. Not many us do understand where I want to go. In fact using the xBase stuff inly neccesary to explain the wish and to implement parts of the feature in the current VFP version, In fact much of (not all) could also be done with a SQL syntax. Just see it as a FILTERED cursor wich is writable (so direclty on the original datasource) but also have to posibility of using JOINS with the same properties.

>If VFP 7.0 came out with this functionality, not only would I not use the new 'feature', I would probably quickly start using another tool besides VFP. There are huge areas of real advances that the VFP team could be working on,

And more speed is one of the items high on my priority list. If VFP is going to abondon speed, I'll probably looking for someother tool (maybe powerbuilder).

>and if found that they had been spending time on this, I would know for sure that they were led by a monkey with no vision of the future.

Clearly you didn't read the entire thread or don't understand much of the relational model to see that this wish is trying to implement a features that has been done wrong in SQL.

>If there is a problem with the performance of SQL access to tables the way it is implemented now relative to performing similar tasks through xBase commands, it means that the VFP team needs to improve performance of SQL access, not attempt to make xBase methods more usable.

The performance issue of SQL lies in the nature of SQL itself, not the VFP implementation.

>IMHO, an approach like yours would be a 10 mile leap backwards in all the advances that VFP has made.

In fact VFP actually FP got famous because of pure power. I just want to extend pure speed and power.

>I have been using VFP for a little over 2.5 years, and NEVER, NOT ONCE used any of the following commands:
>
>SET RELATION
>SET KEY
>SET SKIP TO
>SET FIELDS
>
>I don't even know how to use this stuff, I would have to look at the VFP help.
>
>I have written a fair share of applications, none of them with a performance problem. Not to say I never ran into performance problems, but I worked around all of them without using the commands above.

Performance problems is always relative. As you say, you have found ways to get arround them. Is this a constructive solution ? I think not. I choose for being able to use pure power to blow the hell out of SQL equivalents, and to do thing that are simply not (acceptable in terms of performance) possible within SQL.

>I believe that MS expanding on VFP's xbase capabilities would be VFP's death warrant, because it would be a sure sign that VFP is not moving with the rest of the world.

I've got another vision. If MS inplements my vision implementing the relational language in a VFP manner, I believe VFP has a VERY HUGE performance advantage over any other RDBMS product currently available.

For example (however it's practice might be doubtfull) take two farily large tables (say about 100.000 records or more) and create a SQL cartesian product and mesure the time.

Within xBase you can do the following to reach the same:

Set a one to many relation between the two tables and browse the table. If the index of the child table is on character field you can do something like to following (though i've not tested this yet)

USE TABLE1
USE TABLE2 ORDER TAG somecharacterindex
SET RELATION TO "" INTO TABLE2
SET SKIP TO TABLE2
BROWSE FIELDS allfieldsfromtable1, allfieldsfromtable2

Your ready to print your report with a fraction of a second. While you wait to the SQL command to finish and slowly reaches the 2 GIG limit I tell you that though this implementation is done with the use of xBase commands the actual implementation should hide these commands and provide some more user friendly approach to do the same. Maybe this can be done within some sort of SQL (like) statement.

Walter,