Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!tellab5!chinet!dhartung
From: dhartung@chinet.chi.il.us (Dan Hartung)
Newsgroups: comp.databases
Subject: Re: The Rushmore Technology from FoxPro
Message-ID: <1991Jun09.220809.10475@chinet.chi.il.us>
Date: 9 Jun 91 22:08:09 GMT
References: <1991Jun1.165211.27480@ugle.unit.no> <1991Jun07.060129.7177@chinet.chi.il.us> <45@dworkin.UUCP>
Organization: Chinet - Chicago Public Access UNIX
Lines: 56

shevett@dworkin.UUCP ( Sysop) writes:
>dhartung@chinet.chi.il.us (Dan Hartung) writes:
>
>>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)

This is true.  I guess I was just happy to get the extra performance when
I put in an EMS board that I didn't pay attention to what it DIDN'T do!
Still, if the expanded memory is there and available, Fox will just take
it without asking (you can turn this off of course!).

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

Yes.  Included with the package is an "Extended Mode" FoxPro for 386s and
486s, and I believe this is connected w/ the extended memory usage.  It
is confirmed that Fox will use XMS just as it will EMS, though the only
caveat is that I'm not sure you can do this on a 286, since you can't run
the "EM".  

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

Well, I'm told by "experts" that it's "safer", whatever that means.  For
one thing, indexes should be on STR(number), and use the full syntax
STR(number,1,length) or the index will eventually break, even on Fox.
And the character field lets you store a "n/a" value or "unknown" as opposed
to 0.  Also, this can affect the index order for things that look like
numbers, but really shouldn't be handled that way -- e.g. zip codes.
53545-1234 will index after 53546 if you're not careful.  I guess I should
have said that you should consider character fields the default, and only
use numeric when necessary.

-- 
Daniel A. Hartung           |  "What's the difference anyway, between being
dhartung@chinet.chi.il.us   |  safe and being rad, the joke's on us, we've
Birch Grove Software        |  all been had."  -- John Wesley Harding
-----------FoxPro Programmer Looking For Work--------------