Jim,

>You have repeatedly said that folks don't understand what you are proposing. I, for one, understand exactly what you are propsing and I believe that ist is not something I would want to see the VFP developers at MS spending their limited time on. Because I disagree with you does not mean I don't understand what you are proposing.

I do know you as a general exception when it comes to the Relational Database theory. The remark certainly did apply to you. Let it be clear: If folks don't understand what i'm saying, it's clear that it's my mistake, not theirs. I'm certainly suspecting that i've done a poor job to explain why I want this feature.

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

>You seem to indicate that your proposal is the only way to get "more speed" out of VFP. I don't agree. The areas of speed that I want to see addressed is object instantiation. I have lots of choices when it comes to munging data, but to CreateObject() is to CreateObject().

I fully agree, however I'd like to see more power and speed on the database side.

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

>Again with the relational theory, I propose that it is you who is weak in teh area of relational theory if you think using record oriented commands is relational. At best you suggestion is to use non-relational techniques that are disguised as relational.

The mentioned record oriented commands are needed to at least explain what i'm doing here. In fact if this wish was accomplished I would not bother if these commands dissappeared from the language itself; they're not needed anymore because it all could be accomplished with the VFP view i'm proposing. What's going on under the hood doesn't concern the end-developer.

Another issue is that i've got trouble to call these commands (SET RELATION, SET FILTER, SET SKIP etc) record oriented. They apply to whole tables.

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

>That is flatly not true. SQL does not have inherent weaknesses related to performance. Poor preformance can be gotten with SQL and with xBase, and with any other tool. For one example, SQL Server is as fast if not faster than VFP in most situations (given an even playing field).

Jim, Again the performance issue involved with SQL is that it actually makes copies of the data (stored in a temporary file or memory) whereas the VFP view does use the data itself, gathering the data when adressed.

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

>Actually, FoxBase got famous because it precompiled to p-code when dBASE III didn't. It also ran 7 times faster than dBase III. FoxPro got famous because it had a graphical style interface in a character mode DOS environment. FP 2.0 introduced Rushmore for query optimization and VFP 3.0 introduced Object-Orientation.

I see rushmore as the biggest advantage.

>Fox products have never been a complete RDBMS and it never will.

I'll never argue this.

>>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.
>
>If you want to use pure power to "blow the hell" out of performance problems then your best bet is to write your own xBase code,;

I want to absctract the xBase code needed for the job into relational operators.

>or better still write your own database system in C++. I don't think for a moment there is any way for VFP to determine the optimized xBase evironment for a given query without sepcific knowledge about the data model.
To accomplish that task would require an artificial intelligence system that could learn from mistakes and better optimize in a specific system differently over time improving with each lesson.

What about enhancing rushmore ?
AI is a dead term, Query optimizers are all arround us, though most of them are still fairly weak especially when it comes to DDBMSs.

>>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.
>
>Again you mix the terms Relational and VFP manner.

Agree fully here. Sorry I mixed them up (though I do not seem to be the only one here. VFP is marketed as a RDBMS), tough it's fairly difficult to explain to others that in reality a RDBMS does not exist. To avoid confusion with other DBMSs (like a hierarchical), it may be justified to call it a RDBMS.

>VFP is NOT relational, the VFP youa re referring to is the xBase DML and the xbase DML is not even remotely relational. It is an ISAM engine that can implement relational designs.

See above. If we implement this feature, we wouldn't need these commands anymore. They're only used in the internals of the mechanism. We can work with the 7 (out of 8) relational operators.

>>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)
>
>In a relational system you shouldn't need to know what the index is. I won't bother picking on your code because you only used it as an example.

I don't see that it should, this matter is not overcomable, The VFP team could easely implement this without an index, though you would lose the benefit of speed.

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

>Here you are insinuating that the Cartesian product is a desirable result. Interesting, could give an example where it is desirable. I have always seen the Cartesian product described as an interesting mathematical curiosity that is never desired.

A full cartesian product is seldom reqiured, but I can imagine some applications for statistical, scientifical and mathematical systems. Maybe for chess programs or programs to make a timetable for schools where you've got to deal with students, courses, teachers, classrooms and time.

Restricted cartesion products where the combinations between the two tables are somewhat restrictive occur more often (again, see above applications). For myself i've used one or two of these restrictive ones (implemented the xBase way, because it would be fairly impossible to do it with SQL).

But this not really the issue here. I did want to give an (extreme) example where my aproach is much faster than the SQL approach (again, because it copies data)

The whole idea is to make it possible to get the 8 relational operators into the VFP environment (though it will be a problem by implementing the union, for so far as i can see it) without having to copy the data in a simular form (which SQL does), giving you a tremendous boost in terms of performance, memory management, and CPU cycles.

I'm beginning to realize that i've should been more clearly to the issue, and should have beginned with the desire to implement the 8 relational operators.

Walter,