Hi Gerry,

>Adding a feature like "2-way" is NOT an entirely different foundation. It's simply an "option" that you can choose to use or not.

Yes ! This is what we need badly. It's just like we have two ways of handling data: SQL and xBase. And this is exacly why VFP is so powerfull when handling data. I'm seeing the majority constantly ask for more support for SQL and using external data, but i seldom see ERs for enhancing the xBase DML component while there is much to gain in this area. VFP could be significantly faster if the emphasize is put on other things like:

- Make Filtered indexes optimizable (can have huge advantages for rushmore).
- Passing rushmore-optimizer hints in optimzable expression (e.g. which indexes to use or not to use)
- Get rid of the overhead in VCX, SCX, etc. files
- Allow customization of the bufferize used by open tables. which could decrease the time needed to open tables significantly.
- Get rid of the overhead in FPT files (first 512 bytes are practically unused)
- Introduce new datatypes for tables like: Byte (1 byte unsigned numeric), Short (2 bytes unsigned numeric). Dates using 4 bytes instead of 8.
- Pass reference off tables (and thus also cursor) from one procedure to another.
- Compress all tables (like DBF, SCX, VCX, FRX) when included in a VFP executable. This will dramaticly reduce the size of a VFP executable (to about 25%)
- A new setting for tables so we can ignore deleted records totally (thus indexes are scoped to non-deleted records, optimizing rushmore and bypassing the frequent problem of the uniqueness violation of primary or candidate keys when a duplicate value exists in a deleted record)
- Introduce native record-recycling (Is not possible with views currently)

All those wishes (from my standpoint) would not be particular difficult to implement in VFP.

>EVERYBODY who has tried it, likes it. Is that a majority ?
>
>Or is it still a minority because the majority of VFP programmers have not tried it ?

I think the problem is here that the majority of messages on the UT are about different subjects than what the majority of the VFP developers are wrestling with. For example n-tier is a hot subject here, but when looking at the numbers (from a survey) it seems that still 85% is mainly developping single tier apps, while we certainly don't know if the participants of this forum are a correct reflection of the whole VFP community.

Your proposal could be a valid wish for VFP 8. Though I've not read all messages in this thread could you explain what advantages your proposal would have over the use of VCX files ? Maybe more important, do you have any idea what this means in terms of effort for the VFP-team ?

>Frankly, I think it's irresponsible (as professionals) to say that the "majority thinks this or that" without having any facts to back it up, and then take oneself off the hook by saying it's "just an opinion".

This a dangerous area, that have parrallels with politics. Frankly, I do believe that the majority themselves don't know what they want until a smart guy stands up saying that he has invented, or has thoughts about something new, even though this new thing turns out to be a hype after some time. In a sense, VFP-developers are, like all people, a bit like sheep.

Therefore, I don't like to be in the shoes of the VFP-team, where they have to decide what to include and what not to include. The dangerous thing is that many requests of a few people is honored, while the obvious needs (like more performance) don't get the attention it needs badly to distinguish the product from others.

>It the final analysis, it winds up being a comment that would have been better left unsaid; sort of like: "the majority thinks the sun will not rise tommorrow ... in my opinion".

Like I've been experiencing in the past, the majority thought that using an INDEX on DELETED() would speed up queries. It turned out to be the majority was wrong.

Walter,