Groetjes

Thanks for the thoughtful post, Walter.

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

I think "performance issues" are things you become sensitive to only when you yourself have had to endure some of the "waiting" (I always test with production class databases).

>> - Make Filtered indexes optimizable (can have huge advantages for rushmore).<<

The thoughful use of SET KEY has solved some of my "filter problems" ... (VFP doesn't always take advantage of an index as I thought it should).

>> - Passing rushmore-optimizer hints in optimzable expression (e.g. which indexes to use or not to use)<<

I think it's called "preparing" or "pre-compiling" the query where the Query optimizer determines the best access strategy and maintains statistics for future consideration. The Access Jet Database engine does it (among others).

That's why I frequently replace (VFP) SQL with SEEEK ... SCAN ... WHILE.

>> - Get rid of the overhead in VCX, SCX, etc. files <<

2-way text files.

>> - Allow customization of the bufferize used by open tables. which could decrease the time needed to open tables significantly.<<

.NoDataOnLoad ? SYS( 3050 ) ? USE ... NODATA ?

>> - Get rid of the overhead in FPT files (first 512 bytes are practically unused)

Using a BLOCKSIZE of 0 is one way to take to "byte" out of memos (though it doesn't address the header).

>> - Introduce new datatypes for tables like: Byte (1 byte unsigned numeric), Short (2 bytes unsigned numeric). Dates using 4 bytes instead of 8.<<

Yep ... a lot of space is wasted storing numerics in DBFs. Binaries would also give some measure of "encryption" if the file extension was disguised.

>> - Pass reference off tables (and thus also cursor) from one procedure to another.<<

I'm using the Session Class to encapsulate Queries, "Lookups", and "mult-select picklists" and then pass those around between other Forms, Dialogs and Processes. These "Dataset classes" have methods that enable the "outside world" to get at their contents.

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

With 2-way and text-based classes, you've eliminated the SCX/VCX/FRX; no more bloat from that area.

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

Yes. I seems only DBFs do not have "built-in" facilities to manage "deleted space".

All good points.

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

Many of these point were brought up by others (who see the merit of "text" vs "tables").

The single most important point to remember from a IDE "User" point of view, is that moving to a "class repository" that is text-based vs VCX/table based, is totally transparent. One still uses the same "designers" to create the intial Form, component, etc.

Text-based:

- More compact

- Choice of editor when not "painting". Granted, unless you used the VFP "editor" you might not have "intelli-sense", put that's a personal choice. I like my editor (PWB). I want "my" editor ... for coding "logic".

- Source control (ie. VSS) is vastly simplified.

- With a "right-click", I "browse" .C, .PAS, .HTM, .PRG, etc. in the Windows explore when looking for that particular "snippet" to port ... not so with a SCX/VCX. It's a major production probing the "foundation classes" for ideas.

- Changing a "text file" is obviously a lot simpler that hacking a VCX when changing the "parent" of objects in a class (ie. AS ...), etc.

- I do a lot of "cloning" of Forms. A Purchase Order, is like an Invoice, is like a Sales Order. Create one, clone it, make some "global changes" with my powerful "text editor" and I'm away.

- Where am I using this "Field Name" ? TS *.PRG WOMDOCNO /S /LOG>TS.TX ... Norton reads all my PRG's in said directories and creates a listing showing every line and program where WOMDOCNO is used. My editor can call up every PRG and chane the reference for me. VC++ has "browser databases" ... probably will support any language.

There are probably others ... I just do think about "text" when I'm working with it ... I'm at one with the process ... I'm in the "mental model" ... I'm at one with my app ... time and space have no meaning ...

VCX-based:

Frankly, I cannot think of any advantage. At this stage of the game, I think it's probably a lot more difficult (for VFP) to take an object "that is in memory", parse it by iterating thru its controls and then "decompiling" into a VCX vs simply spitting out a DEFINE CLASS in text.

As a matter of fact, that is how I convert my FPW BROWSES to GRIDs. I instantiated each BROWSE, parsed the "BROWSE object" (ie. Grid) in memory, and then "re-wrote" as a .PRG containg a DEFINE CLASS.

>> Maybe more important, do you have any idea what this means in terms of effort for the VFP-team ? <<

Many, if not all of the features required for 2-way are in Visual Studio's IDE; can't the VFP Team "borrow" some of then ?

The fact that VFP is an interpreter seems to (probably) make the port is even simpler that say for a "native compiler" like .C or Delphi/Pascal (HTML and VB employ "interpreters", as such).

There is one "major" language construct in VFP that (may) have to be addressed; ie. object hierarchies.

Currently, a VFP class can only handle a single-level ADD OBJECT; it needs to support multiple levels, like VB, Delphi and XML, for starters.

These languages have the equivalent of a

OBJECT ... AS <class>
   OBJECT ...

   etc.   

   ENDOBJECT 
ENDOBJECT

The above is not mandatory, however. We could still live with ADD OBJECTs that "call" a DEFINE CLASS that "call" other ADD OBJECTs, etc.

The main issue is that even though the current Object Browser spits out "source", when it comes to hierarchies, it "fudges" them in such a way that they don't compile.

The problem could be solved by generating (intermediate) "pseudo-classes" (as in the case of Pages in Pageframes); this "pseudo-generation" was employed frequently in FPW when it came to procedures/procedure names.

The final key in all this is that whether a formal new language construct is added to the language or some sort of pseudo-classes are generated, the end product (ie. the text-based .PRG) is compilable, runnable, modifiable by "any" text editor, and barring "coding errors" can be read again by the "visual tool" to redender an "image" that can be manipulated at design time.

But the "text" vs "image" has to be available (in a window) at the click of a mouse (ie. switching "Views"), not some "process" where we have to run a bunch of "conversion programs". We already have those.

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

Yes. "We" need more "living space" ...

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

Yes, well, I keep hearing: "well, you can buy this, to do that, so we don't have to build it".

We have a number of Clients that use our product; if every time we told them to go buy this or that when they wanted to E-mail from our app, or produce a graph, etc. they would tell us to go **** ourselves.

For some reason, this doesn't apply around here. There's a lot of cronyism going on (including between MS and developers) and "if I didn't think of it, it can't be that good".

And since the above "is only my opinion" and since I'm adding a lot of "smiley faces": :) :) :) ... it makes it all "OK", OK ? :)

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

VFP has it's icons/cult figures ... Woe be onto thee if thy question their commandments lest their minions take notice and smite thee down... :)

(... too many years in the corporate world ...).