ANOMALIES UPLOADED ON 05-15-89
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
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
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.
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
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
The workaround is to EDIT the resulting .DBF file (e.g.
Aaa.DBF). Changing each record's FIELD_IDX contents to "Y"
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
Bits 0,1,2 indicates the version number
Bit 3 indicates the presence of a dBASE IV memo
Bits 4,5,6 indicates the presence of a SQL table
Bit 7 indicates the presence of dBASE III
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
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"
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.
? 5.0 / 5.0000001
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:
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.
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.
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
APPEND FROM ... SDF with exponential data
An APPEND FROM
in exponential notation, while correctly storing the data
internally as fixed format, displays the data in exponential
USE filename && one numeric or float
APPEND FROM filename TYPE SDF && text file contains
15E+02 && how value is displayed
1500 && proof of internal storage
The above example assumes the width of the numeric field is
long enough to include the full exponential expression.
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:
Additional fixes for Label.GEN
There have been several changes incorporated in the new
Label.GEN file supplied since April 7,1989. The corrections
1. If the first field of a label was placed on a line
other than the first physical line of the label, the
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
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
(This error occurred in all previous versions of
3. If a field is placed on a line and a literal character
is the only thing following the field on the line, the
"IF LEN(TRIM( tmp4lbl[1,3] + )) > 0
Error on line ---: bad EXPRESSION"
is returned during compilation.
(This error existed in all previous versions of
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
All queries open database files with the syntax USE
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
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
When file handles have been lost in this fashion, QUITting
dBASE is the only way to "CLOSE" the open file handles.
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
Error on line 177: Syntax error
(the line numbers above will be dependant on your
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