Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!jarthur!uunet!brunix!cs.brown.edu!pew
From: pew@cs.brown.edu (Peter E. Wagner)
Newsgroups: comp.databases
Subject: Re: FoxPro questions
Message-ID: <73956@brunix.UUCP>
Date: 30 Apr 91 05:07:18 GMT
References: <1991Apr29.141335.19497@mccc.edu>
Sender: news@brunix.UUCP
Organization: Brown Computer Science Dept.
Lines: 74

In article <1991Apr29.141335.19497@mccc.edu>, shevett@mccc.edu (Dave Shevett) writes:
|> We have some 'oddities' cropping up in FoxPro, and we're wondering if some
|> folks should shed some light on them:

You pose some toughies...

|> 
|> 1 - We use 'foxswap' to shell out to applications we're calling from the
|> programs.  (A graphics routine, and a communications program).  THe problem
|> is, repeated usage of this functions tends to accumulate lost clusters on
|> the drive.  Has anyone else seen this phenomenon?  We're having a helluva
|> time finding what's cauusing it.

I'm sure you know that FoxPro creates a temporary file on the disk
which it uses for swapping (this is for general use, not just for
foxswap).  If FoxPro is not shut down properly, this file is left
around and causes chkdsk to find lost clusters.  I guess that foxswap
creates another file or uses the same one mentioned above.  Fox says
they don't do anything special with this file, it's just a DOS file,
but everyone knows that there's something funky there that causes lost
clusters.  My guess is that with repeated shelling, FoxPro gets
confused, and doesn't clean up after itself as it should.

|> 
|> 2 - We have a menu that has a pick that may or may not be available, 
|> depending on the existence of a file.  The applicable code follows:
|> 
|> 
|> oblslash = iif(file(filename),'','\')
|> 
|> define menu reps
|> define pad obl  of reps prompt oblslash+'3  Out-Bound Bills of Lading (003)'  at 7,30
|> define pad exit of reps prompt '9  Return to Main Menu           ' at 10,30
|>                                                                         
|> on sele pad obl  of reps do rpick with pad()
|> on sele pad exit of reps do rpick with pad()
|> 
|> The problem is the first time we ACTI the menu, it comes up with option
|> 3 disabled, like we want it to.  Then we hide it, and deac it.  The *next*
|> time we make the pick for this menu, option 3 is still not available, but
|> is not greyed out on the screen.  This is more annoying than a problem, but
|> we're curious what's causing it.  Any suggestions?

Sorry, no idea.  Don't have a PC handy for testing...

|> 
|> 3 - Our most critical problem is with memory.  We want to upgrade all our
|> customers to FoxPro, but it's memory appetite is appalling. Since we use
|> Carbon Copy to support our customers, and it munches up 60k when loaded,
|> we're usually left with right around 500k of memory.  I don't want to argue
|> with QEMM on every steenkin' machine in the world to free up memory
|> (although that does work fine here).  Any suggestions on either getting
|> FoxPro to use up less memory, or shrinking Carbon Copy or freeing up
|> general RAM?

I think you're stuck with QEMM :(.

|> 
|> Thanx for all (if any) responses!

Sorry I couldn't be of more help.  Have you checked out the BB on
Compuserve?  Invaluable!  All the top experts are there.

    Peter

-- 
----------------------------------------------------------------
Peter E. Wagner          (401)863-7685        pew@cs.brown.edu
Department Computer Science   Box 1910        pew@BROWNCS.BITNET
Brown University, Providence, RI 02912        uunet!brunix!pew

Woody Allen when asked if he thought sex was dirty;
                                           `If you do it right.'
----------------------------------------------------------------