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 @...GET...PICTURE...@M 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 @...GET...PICTURE...@M. 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. ================================================================================