Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!caen!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!hacgate!ashtate!dbase!awd
From: awd@dbase.A-T.COM (Alastair Dallas)
Newsgroups: comp.databases
Subject: Re: dBASE IV
Summary: Recursive BROWSE, undefined variables, etc.
Message-ID: <1991Jan28.013215.29306@dbase.A-T.COM>
Date: 28 Jan 91 01:32:15 GMT
References: <1991Jan25.124902.15522@ugle.unit.no>
Organization: Ashton-Tate, Inc.
Lines: 52

Email doesn't work very well for me, so I'm posting this reply.

In article <1991Jan25.124902.15522@ugle.unit.no>, gunnar@imf.unit.no (Gunnar Taraldsen) writes:
> I would much appreciate if someone could answer the following
> questions conserning dBASE IV:
> 
> >> 1. I run into the message: "Insufficient memory ..." when
>       DO'ing relatively small *.prg files.
>       I have all the PROCEDURE/FUNCTION declarations in one file
>       and I suppose I could save some memory if I splitt the file,
>       but then the application becomes to slow.

If you're out of RAM, you're out of RAM.  If your file is very large,
you should split it up (most dBASE applications consist of many small
files).  dBASE IV includes a fairly smart segment loader; I'd like
more information about why your application gets slow using more 
than one procedure file.

> >> 2. Is there a way in dBASE IV to check if a variable is defined
>       and/or wich type it has? I can do it in Clipper, but...

The TYPE() function will return "U" if a variable is undefined.

	A = 1
	? TYPE("A")
	  N
	? TYPE("B")
	  U

> >> 3. Is there a way to avoid using *.fmt (or *.fmo) and still
>       associate PICTURE and FUNCTION options to selected variables
>       when entering BROWSE/EDIT? (I think about speed ... 

No, that's what .fmt files are for.  Generally speaking, having a
few extra files open should not cause noticable slowing--perhaps
there is something unusual about your situation?

> >> 4. Recursive calls to BROWSE/EDIT are not allowed. 
>       Is there a way to get around this restriction?                  

Glad you asked.  Version 1.1 includes a command:

	SET DBTRAP OFF

which will allow you to call BROWSE/EDIT recursively.  You must be
careful to avoid damaging the parent BROWSE's environment (don't
reposition the record pointer, don't close the file, etc).  This
is akin to an 'expert' mode--RTM, page 3-32.

Hope it helps.

/alastair/