regoli@silver.bacs.indiana.edu (michael regoli) (01/24/89)
][
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 more than 95% physically sorted on a
field,
BUT less than 100% sorted,
AND that field is indexed
the SQL optimizer will assume that the field is, in fact,
100% sorted. SQL queries against that field will miss the
records which are out of order.
The most likely ways for a user to get a data file "almost in order"
are:
- the user begins using an application for the first time,
and enters a large quantity of data in sorted order (such as
typing in an address book). The user then starts adding,
deleting, and changing records. While the number of changed
records is less than 5% of the database, the anomaly can
occur if the critical field is also indexed.
- the user has an application which uses the dBASE SORT
command to generate a physically sorted file for reporting
purposes. The application also updates the file. The user then
adds an SQL "addition" to the existing dBASE application.
EXAMPLES:
1. SELECT DISTINCT CLIENTS.ACCTNUM, NAME FROM CLIENTS,
TRANSACT
WHERE CLIENTS.ACCTNUM = TRANSACT.ACCTNUM
AND SYMBOL IN
(SELECT SYMBOL FROM TRANSACT
WHERE ACCTNUM=1002);
2. SELECT DISTINCT CLIENTS.ACCTNUM, NAME FROM CLIENTS,
TRANSACT
WHERE CLIENTS.ACCTNUM = TRANSACT.ACCTNUM
AND SYMBOL IN
(SELECT SYMBOL FROM TRANSACT
WHERE ACCTNUM=1002)
AND ACCTNUM = 1144;
Note 1: This query returns an "Ambiguous column name" error since
the column "ACCTNUM" is in both tables. The last line in example
2 should read "AND CLIENTS.ACCTNUM = 1144".
3. SELECT distinct NAME FROM CLIENTS
WHERE "GM" IN
(SELECT trim(SYMBOL) FROM TRANSACT
WHERE ACCTNUM = CLIENTS.ACCTNUM);
Note 2: One needs to add the "DISTINCT" keyword and the
"TRIM()" function indicated above in lower case to get the
right results.
4. SELECT ACCTNUM, COUNT(*) FROM TRANSACT
GROUP BY ACCTNUM
HAVING COUNT(*) > 60;
WORK-AROUND:
Observe that all four queries involve selections involving the
column TRANSACT.ACCTNUM which is also indexed. This is the field
which is "almost in order". The work-around is to drop the index
on the field.
b) If a query contains an existential predicate ("WHERE EXISTS..."),
AND contains a nested subquery,
WHICH has a local predicate,
AND WHICH is against a table of more than 5,000 records,
then the user MAY get an "Internal Error". The error is
handled normally by dBASE IV's error trapping.
EXAMPLES:
1. SELECT NAME FROM CLIENTS
WHERE NOT EXISTS
(SELECT * FROM TRANSACT
WHERE ACCTNUM = CLIENTS.ACCTNUM
AND SYMBOL = "GM");
2. SELECT NAME FROM CLIENTS
WHERE EXISTS
(SELECT * FROM TRANSACT
WHERE ACCTNUM = CLIENTS.ACCTNUM
AND SYMBOL = "GM");
Note the presence of "EXISTS" or "NOT EXISTS", they make the
predicate existential. Also note the nested subquery
"(SELECT * ..." and the local predicate "AND SYMBOL='GM', a
predicate which is confined, or local, to the table
referenced in the subquery. If the above conditions exist and
Also, if the table in the subquery, TRANSACT has more than 5,000,
the anomaly may occur (it won't always).
WORK-AROUND:
Split the query into two queries, storing intermediate
results in a temporary table.
SELECT * FROM TRANSACT
WHERE "GM" = trim(SYMBOL) SAVE TO TEMP T1;
SELECT NAME FROM CLIENTS
WHERE EXISTS
(SELECT * FROM T1 WHERE ACCTNUM = CLIENTS.ACCTNUM);
c) If a query contains a two-table join,
AND a local predicate on the join column,
AND both join columns are indexed,
then the user MAY get an "Internal Error".
EXAMPLE:
SET SQL ON
START DATABASE SAMPLES;
DROP INDEX ORDER_ID;
DBDEFINE TRANSACT;
DBDEFINE STOCK;
CREATE INDEX ORDER_ID ON TRANSACT(ORDER_ID);
CREATE INDEX ORDERID ON STOCK(ORDER_ID);
SELECT TRANSACT.ORDER_ID FROM TRANSACT, STOCK
WHERE TRANSACT.ORDER_ID = STOCK.ORDER_ID
AND TRANSACT.ORDER_ID = '87-105';
WORK-AROUND:
Drop one of the indexes.
Note: The two-table join (WHERE TRANSACT.ORDER_ID =
STOCK.ORDER_ID), the indexes on both joined columns, and the
predicate condition local to the TRANSACT table. Dropping either
index will allow the query to succeed.
--
|
| michael regoli
| ...rutgers!iuvax!silver!regoli
| regoli@silver.bacs.indiana.edu
|rankin@uoregon.uoregon.edu (6eorge Rankin.) (01/29/89)
In article <3035@silver.bacs.indiana.edu> regoli@silver.bacs.indiana.edu (michael regoli) writes: > >][ > >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... >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 scrap 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."