>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.
Walter,
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.
>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().
>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 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).
>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. Fox products have never been a complete RDBMS and it never will.
>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, 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. I know, for me, the optimization of xBase code that I use is thoroughly based on my insights into the business and the way it manipulates its data.
>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. 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.
>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.
>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.
