Official dBaseIV Anomalies

Official dBaseIV Anomalies

Post by michael rego » Tue, 02 Jan 1990 19:33:00



][

what follows below is the "official" listing of dbaseIV anomalies as
taken from ashton-tate's bulletin board.  the file, ANOMALY.ARC, was
downloaded on 23 january 1989.   it contains:

Name          Length    Stowage    SF   Size now  Date       Time    CRC
============  ========  ========  ====  ========  =========  ======  ====
ANOMALY.TXT       3802  Crunched   45%      2095   1 Dec 88  12:00a  0577
ANOMALY2.TXT      4779  Crunched   46%      2592  20 Jan 89   1:21p  042d
SQLANOM.TXT       5630  Crunched   49%      2913  23 Dec 88  12:00a  c07b
        ====  ========            ====  ========
Total      3     14211             47%      7600  

the telephone number for their board is 213-538-6196.

============
ANOMALY.TXT
============

Thanks for using the dBASE IV product.  The initial customer
response to the dBASE IV product has been positive and this
confirms the product's overall quality.  In keeping with our
commitment to provide you, the user, with support that will
maximize your productivity with the dBASE IV product, we are
continuing our tradition of publishing timely, detailed anomaly
and work-around reports.

Use of these recommended work-arounds will aid you in avoiding
anomalies that are reported to our Software Support Center.  This
report will be supplemented as new information is received.

Reports DETAIL BAND double space ejects blank page

     If the DETAIL BAND is set to double spacing on a printed
     report, one blank page is ejected between each printed page
     and printed pages are numbered 1, 3, 5, etc.

     WORK-AROUND:

     To work around this, you can do one of four things:

     1) Close the footer band.  This corrects the problem but it
     also prevents printing of any specified footer.  The footer
     is open by default in the Quick layout, so this will not be
     intuitive to the end user.

     2) Change the page length to a value less than the line
     length of the paper, which is 66 for 11-inch long paper.
     While blank pages will no longer appear between printed
     pages, page numbers will still be odd numbers.

     3) Modify the report and put extra blank lines in the DETAIL
     BAND and keep spacing set to single for the band.  The
     effect will appear to be a double spaced DETAIL BAND,
     however, this will not work when using memo fields in the
     DETAIL BAND.

     4) Download the file REP_ANOM.ARC from the dBASE IV library
     and copy the REPORT.GEN file over the REPORT.GEN in your
     dBASE IV directory.

EEMS is not supported in dBASE IV version 1.0

     Extended and expanded memory are not supported in version
     1.0 of the dBASE IV product.  Extended memory can only be
     used as a RAM disk.  If you set EEMS=OFF in CONFIG.DB as
     stated in the Language Reference, the error message "Keyword
     not found" will be displayed.

     The two references to the use of extended memory in the
     documentation -- page 6-4 of Language Reference and page
     GS-3 of Getting Started with dBASE IV -- are in error.

Memo edit from BROWSE

     In BROWSE mode only, adding more than 512 bytes of data to a
     memo field that already contains data, pressing ESC to exit
     the BROWSE menu after the memo field is saved corrupts the
     memo file.  This happens only when the record pointer is not
     moved before pressing ESC to exit BROWSE.

     WORK-AROUND:

     To work around this, exit BROWSE by pressing CTRL-W or
     CTRL-END, or by choosing the "Save changes and exit" option
     from the EXIT menu.

     Alternately, move the cursor off the current record before
     pressing ESC to exit BROWSE.

Memo fields limit size of 64K

     Memo fields cannot contain more than 64K of data.  If you
     attempt to save a memo field that exceeds this size limit,
     the system beeps without displaying an error message.

     WORK-AROUND:

     To work around this, you can press ESC to abandon the
     changes, or you can delete some text and try to save the
     memo field again.

CTRL-BREAK locks the system

     If CTRL-BREAK is pressed while in the dBASE IV program,
     subsequent keystrokes are not recognized thus requiring a
     warm boot.  The same is true if CTRL-BREAK is pressed while
     loading the dBASE IV program.  Do not use CTRL-BREAK unless
     you intend to completely stop the dBASE IV product or
     application.

============
ANOMALY2.TXT
============

In keeping with our commitment to provide you, the user, with support
that will maximize your productivity with the dBASE IV product, we are
continuing our tradition of publishing timely, detailed anomaly and
work-around reports.

The following listing addresses three known anomalies when using dBASE
IV. Use of these techniques will aid you in avoiding anomalies that
have been reported to our Software Support Center.  This report will
be supplemented as new information is received.  There are also two
Usage Tips that users can use in order to avoid further problems or
misunderstanding when using the dBASE IV product.

*******************************************************************

                            ANOMALIES

MODIFY STRUCTURE will not create .BAK files

Issuing the command MODIFY STRUCTURE from the Dot Prompt, or hitting
Shift-F2 from the Command Center while highlighting a database file,
will allow modification to be made to the structure of the file.
dBASE III PLUS automatically created a backup file with the extension
.BAK that was a copy of the original .DBF file.  dBASE IV does not
create this backup.

WORKAROUND:

In order to preserve data in the case of a mishap or an unsuccessful
modification of the structure, COPY the database to a temporary file
prior to entering MODIFY STRUCTURE.

USE .dbf filename
COPY TO temp
MODIFY STRUCTURE

=================================================================

Date type Index key expressions in .NDX files coming from dBASE III
PLUS.

Index files created in dBASE III PLUS and used in dBASE IV may return
the error message "Data type mismatch" during operations such as EDIT,
APPEND or SEEK.  Also, users may issue a COPY INDEXES <.ndx file list>
TO <.mdx filename> command to update a production .MDX file with the
key expression from a dBASE III PLUS .NDX file.  

WORKAROUND:

In the case of .NDX files, simply issue a REINDEX command to recreate
the index file under dBASE IV.  Numeric and date data types are now
handled differently in dBASE IV.  In the case of the .MDX if the
database cannot be opened with the updated production .MDX file, the
user may have to delete the .MDX file and create it from scratch.
However, if the file can be opened in dBASE IV, issue a REINDEX
command.

=================================================================

LABEL generation errors when DEFAULT is set to A:

Creating or modifying labels with SET DEFAULT TO A, causes generation
errors.  The first error returned during generation of the .LBG code
is "Generation error 34, label.cod @460" and subsequent to that,
"Generation error 161, label.cod @777   Builtin function 325 failed".

WORKAROUND:

1)   Copy the relevant files to the hard disk, and thereafter,
     MODIFY/CREATE LABEL will not cause generation errors.

2)   Download the file LABEL.GEN and copy the file over the
     LABEL.GEN in your dBASE IV directory.

*****************************************************************

                            USAGE TIPS

.$VM and .$ED dBASE IV temporary files

dBASE IV will create temporary files in the DOS default  directory
during each dBASE IV session.  These files are named with a series of
numbers ending with an extension of .$VM or .$ED.  These temporary
files should be deleted by dBASE after a session, but are not.  They
can be deleted manually after quitting dBASE.  

dBASE IV can be forced to reroute these files to a different location
by using a DOS environmental variable.

For example:
     SET TMP=D:\
          will route the temporary files to a D: RAM disk

     SET TMP=C:\DB4TEMPS\
          will route them to a special directory on the hard    
disk.

Note: A backslash is required as a terminator after all path names.
Also, a period should not be included in the directory name.

=================================================================

SHARE and FASTOPEN cannot be resident during dBASE IV installation

Attempting to install dBASE IV (especially under DOS 4.0) when the DOS
SHARE and/or FASTOPEN  utilities have been loaded will hinder
successful installation of the product.  An error such as "Open file
error" may be returned.  With SHARE loaded, the Install routine may
fail to recognize the insertion of System disk # 1 or # 2.  

Removal of these Terminate and Stay Resident programs (TSRs)/utilities
from the CONFIG.SYS or AUTOEXEC.BAT files or renaming these files, and
rebooting the computer will allow the successful installation of the
product.  After completed installation, these programs can be loaded
as usual through the original CONFIG.SYS or AUTOEXEC.BAT files.

============
SQLANOM.TXT
============

In keeping with our commitment to provide you, the user, with support
that will maximize your productivity with the dBASE IV product, we are
continuing our tradition of publishing timely, detailed anomaly and
work-around reports.

The following listing addresses three known anomalies when using
dBASE IV SQL commands. Use of these techniques will aid you in
avoiding anomalies that have been reported to our Software Support
Center.  This report will be supplemented as new information is
received.

*******************************************************************

The following queries either fail with an "Internal Error" when
executed by dBASE IV's SQL, or give incomplete results.  Three
distinct anomalies are responsible for the seven failing queries:

a)   If the data in a table is
...

read more »

 
 
 

Official dBaseIV Anomalies

Post by 6eorge Ranki » Tue, 02 Jan 1990 22:13:00



>][

>what follows below is the "official" listing of dbaseIV anomalies as
>taken from ashton-tate's bulletin board.  the file, ANOMALY.ARC, was
>downloaded on 23 january 1989.  .......

To summarize:  dBASE IV has some "anomalies"  

   *a)  If a table is more than %95 physically (?relational?) sorted
        and is indexed, joins to that table can miss entries.

    b)  Under some conditions, a query may fail on tables with more than
        5000 entries.  (SQL reports an "internal error".)

    c)  Under some conditions, joins of two indexed columns may fail
        with an internal error.

Item "a" is rather horrifying...

Quote:>In keeping with our commitment to provide you, the user, with support
>that will maximize your productivity with the dBASE IV product, we are
>continuing our tradition of publishing timely, detailed anomaly and
>work-around reports.

But will they offer free fixes to the program?  These are very serious bugs,
and would make me very wary  of using their system.  "Work-arounds" don't
do much good when a program produces incorrect results.  Imagine telling
your payroll department that the reason some (unknown) employees didn't
get their paychecks is because "your table was more than 95% physically
sorted on a field, but less than 100% sorted, and it was indexed.  Of
course you had problems!"  Any good payroll department would immediately
s*the computer system and issue checks by hand.  No kidding.

The dBASE IV SQL errors are the most serious that any computing system
can be guilty of.  Before flaming, think about it for a minute.  A
program that produces incorrect results is far worse than one that crashes.
In human terms: the answer "I don't know" is far preferable to a made-up
answer.  Furthermore, systems that sometimes fail are far worse than
those that always fail.  It looks as if a DBASE IV SQL database could
fail for mysterious reasons after working well for many months.  This
behavior is almost impossible to debug, especially when it is the database
and not the user's application that is at fault.  

Ashton-Tate should at least be congratulated for publishing the errors
to the extent that they have.  (Will they mention them in their next
set of advertisments for dBASE?)  Professional ethics require them
to fix these problems and supply the fixes to their customers.  The
idea of a "workaround" reminds me of the old joke:

      Patient:  Doctor, it hurts when I do this.
      Doctor:   Well, then don't do that!

Relational databases are a wonderful idea.  Let's not give them an
undeserved reputation for being unreliable.

        George Rankin
        Senior Programmer
        Springfield Public Schools

"We have used Oracle for many years and are quite happy with it, even
 though the C precompiler is atrocious."