[comp.databases] dBASE IV bugs

murrell@trlsasb.oz (Phil Murrell - Computer Facilities Group) (07/13/89)

  I have been having some problems with dBase4 that, after talking to the
local Ashton Tate hotline, appear to be bugs in dBase4 V1.0. Perhaps these
bugs are widely known, but I haven't seen any lists of known bugs and
thought that they may save someone else the same problems.
  The first involves the use of the "@M" function in a GET statement. It 
appears to randomly upset PICTURE specifications attached to further GETS
in print statements. I had two examples, the first involved selecting a
type of form to print with the "@M" function and the form when printing
would misalign one of the data fields into the wrong column while leaving
the other fields ok. The second occurred on page two of a multiple screen
form, you could page down from screen 1 on any field except the "@M" field.
If you chose that field, all numerical fields on screen 2 would misalign.
  While this problem wasted a week, the second problem is of more concern
as it seems harder to program around. At what appears to be seemingly
random times, I get an insufficient memory message which always occurs
on a line containing a macro. The PC running the program has approx 530k
of available memory on a NOVEL network with Printer Assist. When it crashes
it has between 35K and 58K of "Available memory". Our local dealer suggests
that I am to close to the limits and did not offer much in the way of fixes.
I have removed all macros and cut back on the variable and run time space
allocations, but I suspect that I still have problems.

 Ashton tate have said that Version 1.1 will be released in September/October
and that it will use less RAM, allow EMS and have fixes for the "@M" problem
among other fixes, but I need a product that can survive until then.

 It would be great to hear about any other known bugs so that people like
myself could avoid them instead of finding out the hard way.

                                                
Phil Murrell
Internet: Murrell@trlsasb.oz.au

keithb@hpindda.HP.COM (Keith Broussard) (07/15/89)

Oh boy, I have had a real time with the "Insufficient Memory" error
too.  But first, let me comment on your first problem (@M).  This is a
known bug by A-T and there is information about it and a workaround in
the DBASE4 area of the A-T Support BBS (You can get the number by
calling the A-T support line and listening to the recording.  I have
not had this problem, so I don't remember the details, but I remember
reading it.

Now, I talked to A-T support too about the Insufficient Memory error
and was  told that dbase4 will report Insuf Mem when it runs out of
its own internally allocated memory, so that message doesn't
necessarily mean that you ran out of RAM.  Try playing with the
BUCKETS parameter in the CONFIG.DB file.  I have a relatively large
application that would fail during deep nesting or VALID function
calls, and I increased BUCKETS to 4 and the problem seems to occur
much less often.  There are some more parms that you might read about:
these parms allocate MVAR space, etc, but it sounds like you might
need more BUCKET space.  I am still playing with those parameters, but
it appears to be helping.

Let me know what happens, please.  Good luck to you.  I must stop now
because I have insufficient memory to complete this message!

Regards!

dukel@dbase.UUCP (Duke Luper) (07/15/89)

In article <10889@trlsasb.oz>, murrell@trlsasb.oz (Phil Murrell - Computer Facilities Group) writes:
> 
>   I have been having some problems with dBase4 that, after talking to the

>   While this problem wasted a week, the second problem is of more concern
> as it seems harder to program around. At what appears to be seemingly
> random times, I get an insufficient memory message which always occurs
> on a line containing a macro. The PC running the program has approx 530k
> of available memory on a NOVEL network with Printer Assist. When it crashes
> it has between 35K and 58K of "Available memory". Our local dealer suggests
> that I am to close to the limits and did not offer much in the way of fixes.
> I have removed all macros and cut back on the variable and run time space
> allocations, but I suspect that I still have problems.

Phil,  give the following company a call about their HICARD product.  It
works with XT's, AT's, 286, 386 machines (all except PS/2's).

   RYBS ELECTRONICS, INC.
   2590 Central Avenue
   Boulder, Colorado  80301

If you have a 386 machine, try a memory expander like 386-To-The-Max.  Any
reasonably knowledgeable computer dealer can help.  Each work on Novell.
In fact, I have been testing on Novell at AT for over a year, and at certain
times it is helpful (if not downright necessary) to use one of these fixes
if you are running a large application.  Do not try to cut down your program
or change its functionality.  I have tried that in the past and, due to the
complexity of dBASE4, it is hard to guarantee when you will increase your
available memory and when you will make the situation worst.  Best of luck.

Duke Luper
Ashton-Tate Multi-user Test

If I say something that will get me in trouble, then I reserve the right to
disclaim it.  "Of course these are my opinions and not Ashton-Tate's.  Whose
else would they be?"