Category : Dbase (Clipper, FoxBase, etc) Languages Source Code
Archive   : DB4ANOM.ZIP
Filename : ANOMALY9.TXT

 
Output of file : ANOMALY9.TXT contained in archive : DB4ANOM.ZIP

ANOMALIES UPLOADED ON 05-15-89


ANOMALY9.TXT


The following listing addresses ten 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.


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


ANOMALIES


INKEY() values different from dBASE III PLUS

Some keystroke values returned for INKEY() have changed from
dBASE III PLUS and the wrong values have been documented in
"Functions", page 4-55 of Language Reference.

The table below contains the values returned from both
products.

Key dBASE IV dBASE III PLUS

Home 26 1
End 2 6
Ctrl-Rightarrow 6 2

On the same page, Ctrl-F is not Ctrl-End but it is actually
just the End key.

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


COPY STRUCTURE EXTENDED doesn't copy the active index tags

If COPY TO filename STRUCTURE EXTENDED is issued when the
file in USE has active index tags, the resulting file's
FIELD_IDX field will reflect a value of "N", incorrectly
denoting an absence of index tags in the source file. This
problem also occurs with COPY STRUCTURE.

EXAMPLE:

USE One.DBF
DISPLAY STRUCTURE
Structure for database: D:\DB4\ONE.DBF
Number of data records: 12
Date of last update : 02/03/89
Field Field Name Type Width Dec Index
1 NAME Character 10 Y
2 COMMENT Memo 10 N
3 NUMBER Numeric 7 2 N
** Total ** 28

COPY STRUCTURE EXTENDED TO Aaa.DBF
USE Aaa.DBF
LIST

Record# FIELD_NAME FIELD_TYPE FIELD_LEN FIELD_DEC FIELD_IDX

1 NAME C 10 0 N
2 COMMENT M 10 0 N
3 NUMBER N 7 2 N

WORKAROUND:

The workaround is to EDIT the resulting .DBF file (e.g.
Aaa.DBF). Changing each record's FIELD_IDX contents to "Y"
when appropriate.

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


dBASE IV Header Structure

The dBASE IV header structure has been documented
incorrectly on the section "Database Header Structure", page
E-2 of Language Reference. Byte 0 information should be as
follows:

Bits 0,1,2 indicates the version number
Bit 3 indicates the presence of a dBASE IV memo
file
Bits 4,5,6 indicates the presence of a SQL table
Bit 7 indicates the presence of dBASE III
PLUS/IV
memo file

All the other information on Tables E-1 and E-2 are correct.

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


@..GET..PICTURE @M ignores subsequent PICTUREs

When @[email protected] is issued, subsequent PICTURE
templates are ignored. Rather than displaying the
respective values in the specified PICTURE formats, the
default lengths and formats are displayed. This will also
affect reports and labels that are run subsequent to
@[email protected]

EXAMPLE:

items = space(10)
mvar2 = "dummy"
@ 5,5 GET mvar1 PICTURE "@M item1,item2,item3"
@ 6,5 SAY mvar2 PICTURE "X" && displays "dummy" instead
&& of "d"
READ

WORKAROUND:

In the beginning of your program initialize a variable to a
null string. Then, GET that memory variable on the same line
as the @...GET...PICTURE "@M" but with the column coordinate
at the right edge of the screen.

junk = ""
...
@ 5,5 GET mvar1 PICTURE "@M item1,item2,item3"
@ 5,75 GET junk
...
=====================================================================================


Division of nearly identical numbers, returns inaccurate results

If you divide numbers whose first 7 significant digits are
equivalent, and whose remaining digits are not equivalent,
erroneous values will result.

EXAMPLE:

? 5.0 / 5.0000001
2

? 11111111/11111112
2.0

? 5/((5/3)*3)
2

WORKAROUND:

Convert one of the operands (the numerator or the
denominator) to a float type value. This can be
accomplished by using the FLOAT() function. For example:

? FLOAT(5.0)/5.0000001

will yield the correct result of 1.00.

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


SEEK() of target file with index tag parameters

If the SEEK() function is issued where the function's lookup
expression uses a field in the current work area, and the
lookup is performed on a file in an unselected work area,
corruption can occur in the currently selected database.

If the SEEK() is performed with a character field, the field
immediately following that field in the file structure will
appear to be blank. If no changes are made to the record in
the selected work area, no permanent corruption occurs.
However, EDITing the record will permanently corrupt the
following field's value.

If the SEEK() is performed with a numeric field, then
DISPLAY STRUCTURE will reveal corruption in the width of the
numeric field. If this damage occurs and the damaged record
is edited, the database will become permanently corrupted.

The same is true if the SEEK() function is issued from
within a .FRG, .LBG or .QBE.

EXAMPLE:

USE File1
USE File2 INDEX Numfield IN 2
? SEEK(Numfield, "File2")

DISPLAYing the current record:

Record# NUMFIELD CHRFIELD FLOFIELD DATFIELD
1 42 42576.35 04/29/62

reveals that data in the Chrfield has been blanked.

WORKAROUND:

If SEEK() is used in a .PRG, store the field to a memory
variable and use the memory variable as SEEK's expression
parameter. If SEEK() is used in a .FRG, .LBG, or .QBE,
create a calculated field whose expression is the field's
name and use this calculated field as SEEK's expression
parameter.

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



APPEND FROM ... SDF with exponential data

An APPEND FROM SDF of a text file containing data
in exponential notation, while correctly storing the data
internally as fixed format, displays the data in exponential
format.

EXAMPLE:

USE filename && one numeric or float
&& field
APPEND FROM filename TYPE SDF && text file contains
&& 15E+02
? numfield
15E+02 && how value is displayed
? numfield*1
1500 && proof of internal storage

The above example assumes the width of the numeric field is
long enough to include the full exponential expression.

WORKAROUND:

Issuing a REPLACE ALL numfield WITH numfield will restore
the display of field values to fixed format. The above
example now has the following result:

? numfield
1500

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


Additional fixes for Label.GEN

There have been several changes incorporated in the new
Label.GEN file supplied since April 7,1989. The corrections
are:

1. If the first field of a label was placed on a line
other than the first physical line of the label, the
error

Invalid or Unknown function
DO WHILE ___&lc_temp.()
Cancel Ignore Suspend

is returned when labels are printed and a label that
requires blank suppression is reached. Placing a
literal blank space on the first line of the label will
prevent this error from occurring in addition to the
solution found in the new .GEN file.
(This error was new to the 2-22-89 version of
Label.GEN.)

2. The SAMPLE routine produced sample labels to test label
alignment, but the sample labels contain one line too
many per label. The workaround for this error is to
modify the .LBG file and to remove the first question
mark (?) after the line DO WHILE choice = "Y" in
PROCEDURE SAMPLE.
(This error occurred in all previous versions of
Label.GEN.)

3. If a field is placed on a line and a literal character
is the only thing following the field on the line, the
error message

"IF LEN(TRIM( tmp4lbl[1,3] + )) > 0
Error on line ---: bad EXPRESSION"

is returned during compilation.
(This error existed in all previous versions of
Label.GEN.)

Download the updated file Label.GEN from the dBASE IV
Library and copy it over the Label.GEN in your dBASE IV
directory. This new Label.GEN also incorporates the fixes
that were included in the Label.GEN that was uploaded on
1-20-89, and 1-27-89, and 4-07-89.

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


Queries containing the USE AGAIN phrase, lose file handles

Opening files with the syntax USE...AGAIN causes the
permanent loss of file handles during the current dBASE IV
session.

All queries open database files with the syntax USE
AGAIN. This command opens the file in a manner
that allows the same file to be opened simultaneously in two
work areas. This technique is required in QBE files when
performing self-joins, as documented on page 7-25 of Using
the Menu System. Files USEd with the AGAIN clause can be
closed but dBASE is unable to release the file handles they
required.

As a consequence of the fact that USE...AGAIN causes the
irretrievable loss of file handles, repeated opening and
closing of queries may ultimately result in the loss of all
available file handles, and the return of the error message
"Too many files are open".

The current number of files open can be viewed at the Dot
Prompt with the DISPLAY STATUS command. dBASE IV starts up
with three files open. The total number of "dBASE" file
handles that can be used is set in CONFIG.DB (not in
CONFIG.SYS!), and the default is 99. That is, the number of
file handles available is 99, regardless of the number set
in CONFIG.SYS.

When file handles have been lost in this fashion, QUITting
dBASE is the only way to "CLOSE" the open file handles.

EXAMPLE:

Set up a query that links two files, or set up the self-join
query as described on page 7-25 of Using the Menu System.
Exit to the Dot Prompt and DISPLAY STATUS. In one case 13
files had been opened. Going back to ASSIST and modifying
the query, then issuing DISPLAY STATUS showed 25 handles
used. Issuing CLOSE ALL, then just opening the query showed
31 handles in use. CLOSE ALL, modifying and saving the
query showed 36 used. A final CLOSE ALL showed 30 file
handles consumed. Issuing CLOSE ALL/CLEAR ALL has no effect
on these lost file handles.

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


Additional fixes for Report.GEN

The Report.GEN file has been updated to correct the
following two errors. These errors existed in the
Report.GEN file dated 2-2-89:

1. An un-named calculated field located in the detail band
and set with the option to Suppress repeated values:YES
will cause an error to be returned when the .FRG file
is compiled. The error will be:

IF .NOT. (r_msrv1 = )
Error on line 176: Bad EXPRESSION

r_msrv1=
Error on line 177: Syntax error

(the line numbers above will be dependant on your
report.)

2. If the menu option Bands:Page heading in report
intro:NO is chosen, the intro band is printed without a
report header band. In addition, the report summary
moves below the page footer band in the MODIFY REPORT
design screen. When this option is chosen and a Pageno
predefined page number field is placed in the page
footer band, no error is returned but the resultant
reports are page numbered 1,3,5... and blank pages are
produced for pages 2, 4 and 6.

Both of these errors have been corrected in Report.GEN files
dated 4-13 and later.

Download the updated file Report.GEN from the dBASE IV
Library and copy it over the Report.GEN in your dBASE IV
directory. This new Report.GEN also incorporates the fixes
that were included in the Report.GEN that was uploaded on
02-02-89.

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