Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!princeton!njsmu!mccc!dworkin!shevett
From: shevett@dworkin.UUCP ( Sysop)
Newsgroups: comp.databases
Subject: Re: The Rushmore Technology from FoxPro
Message-ID: <45@dworkin.UUCP>
Date: 9 Jun 91 02:19:07 GMT
References: <1991Jun1.165211.27480@ugle.unit.no> <1991Jun07.060129.7177@chinet.chi.il.us>
Lines: 61

dhartung@chinet.chi.il.us (Dan Hartung) writes:
>oysteing@idt.unit.no writes:
>They are claiming that it beats DB2 on an AS/400 operating on an identical
>one-million-record database.  I think this was on a 386 machine; have to
>check my papers.

Don't have any paperwork here either, but it's probably on a '386 
with EMS implemented properly.  That's what makes FoxPro happiest.

>>My impression was that the technology is based on some technique where
>>indexes occupy much less space than usual. 
>Compact indexes are one of the featurs of the new FoxPro.  In and of
>themselves, however, they don't constitute the RushMore technology.
>What they are doing is using indexes with a number of commands that
>previously did not use the indexes:  xBase LOCATE and COUNT commands,
>for instance.   

This is an interesting point.  In xBase products, a Locate function would
do a non-indexed SEEK of a file, but without using any indexes.  The
advantage was it had some form of REPEAT function, which would search for
the next occurrance of the expression.  Since 2.0 will support LOCATE's via
Indexes, does that mean the REPEAT function (or whatever it's called) will
work correctly?  If so, it could be a great boon in simplifying group
searches.

>>I seem to remember reading on this group that FoxPro needs a lot of
>>memory. What happens if all indexes does not fit into memory? Is there
>>a significant decrease in performance?

>FoxPro operates impressively well for an xBase product on even a 640K XT.
>When you give it extra memory, though, it takes off.  It makes automatic
>used of expanded memory; 

CAREFUL HERE!  The biggest fault in FoxPro 1.02 is that it does *NOT* make
complete use of Expanded memory.  It will only cache indexes and dbf info
in the expanded RAM, and no memory variables or program code will go there.
Therefore, you may have 16meg of expanded memory, but it doesn't help you
one whit if you program needs 200k of memory variables (which one of our
system's does).  If you have a program that needs to FOXSWAP out to another
app (which we do), it's very difficult running FoxPro, even with an EMS
manager installed (we use QEMM, which lets us use FOXQ, but it's still a
tight squeeze)

>Fox 2 will use extended automatically, but now
>you have to use a (well-behaved) EMS emulator if you only have extended.

Really?  Extended memory automagically detected and used?  Could you
confirm this?

>>The table used for the demonstration consisted of only character
>>fields. Does an index of an integer field take much more space than an
>>index of a character filed? 

>xBase is not very good with number fields.  In general numbers are best
>stored as a character representation anyway.

EXCUSE ME?  I'm confused here.  Why would you use character representations
of numeric fields?  Seems pretty dopey to do a VAL conversion whenever
retrieving from the database.

Dave Shevett - shevett@dworkin.amber.mccc.edu - Lawrenceville, NJ