I don't know if everyone will call these thing bugs, anomalies or simply my own ignorance and sloppiness, but I am placing these notes in the public domain so that others may profit from the time I lost, and not repeat the same mistakes. This is a report of DBASEIII PLUS Version 1.0 BUGS. According to ASHTON-TATE I am using their corrected version. The original release was buggy and recalled. It has very low serial numbers, but unfortunately, I don't know what range was encompassed. This report ignores the numerous bugs which appear in the reports, formats, and labels generated by ASSIST. ASSIST is definitely useable, but all files created may have errors and need to be checked. CONFIG.SYS FILE has FILES=20, BUFFERS=40. Using AT clone 101% compatible running at 8MHz, DOS 3.1, 44Meg disk, Taxan 640 display with Taxan 555 card. DBase 3 Plus is legitimate copy with '0' time logo, and unprotect from 'Unlock Disk' so I can back up and restore easily from hard disk to streaming tape. ******************************************************************************* 'Too Many Files Open' This message may appear despite the fact that you have set your CONFIG.SYS file so that files=20 and buffers=20+ There are at least two causes for the problem and several fixes and work- arounds. The cause of the problem according to Steve at Ashton Tate is that the CLOSE command does not necessarily close the DOS FCB's (DOS file control blocks. Thus after a series of file openings and 'CLOSES', you can exceed the DOS limit of 20 open files and trigger the 'Too Many Files Open' Error Message. A second cause of the problem may be because the files were opened in a Procedure. Fixes, Work-Arounds, and Comments Steve (AT) suggests that a CLEAR ALL will close the open FCB's. I have found that this does not always work, and of course, is not always a desireable command to implement in the middle of a program. USE seems to be a far more reliable method which works, and causes much less havoc in my programs. Also, there is a dependence between CLEAR ALL, CLOSE DATABASES, and the order in which they are executed. Thus, CLEAR ALL doesn't always close the FCB's, as DB3P may not always remember that there are any that need closing. The USE command has proved effective for me 100% of the time. That is, issuing a USE with no following database name closes all files in that database area. A second area of concern has to do with the files opened from a procedure file. I suggest that you make sure that you close these files in the procedure when you are done, and do not make the mistake of assuming that CANCEL closes procedures or the files in the procedure. Use 'USE' and SET PROCEDURE TO in order to close procedures and files opened within procedures. ******************************************************************************* Syntax Checking Entered the letter T instead of the letter F when typing ENDIF in a program. DBASEIII Plus seems to get confused. That is, ENDI is a recognizeable command, so DB3P did not choke on 'ENDIT' ENDIT is not in the DBASEIII Plus vocabulary, but when executing the program, no bad sysntax or bad command verb error appears! DBASE simply ignores the command. This is a disaster because it is tough to spot the error and because the program acts as if it is missing an ENDIF. IF YOU TYPE 'ENDIT' FROM THE DOT PROMPT YOU WILL GET AN ERROR MESSAGE. - - - With SET TALK OFF, "SET DEVICE TO PRINT NO EJECT" is accepted as a correct command. The proper command does not, of course, include NO EJECT, and the phrase NO EJECT is only correct if written as NOEJECT. Fixes, Work-Arounds, and Comments FIX: TAKE A TYPING COURSE AND PROOF READ VERY CAREFULLY. ******************************************************************************* Indexing I Indexed on a compound set of fields which included a character field as the first entry and the compliment of the record number as the 2nd field. [INDEX on ACCOUNT + STR(-RECCNO()) to FILENAME] BROWSE present a Record not found error just like the old index bug in DBASEIII 1.0 AND 1.1 (the one which is solved by indexing on fields with lengths which are multiples of 4). Fixes, Work-Arounds, and Comments You must set the length of the STR function when doing an INDEX. [INDEX on ACCOUNT + STR(1000000-RECCNO(),6) to FILENAME] works fine. - - - 'File Not Accessible' SET TALK OFF (Source Tom Wells and Bob Schniebolk) 1. With SET TALK OFF issued a USE TCUST INDEX TCUST,TCUSTNA,TCUSTZI,; TCUSTAD REINDEX 2. DBASE 3 Plus responds with "File Not Accessible" (sometimes) Fixes, Work-Arounds, and Comments FIX 1: SET TALK ON REINDEX FIX and Comment 2 (per Tom Wells and AT): A - Set Talk on and Reindex now interact! B - If you must Reindex, Set Talk On. C - Watch % Index numbers. If they jump immediately to 100 % you are NOT reindexing. (NOTE: I have found that this is not always the case. If the file is small and you are using an AT, the indexing may be near instantaneous and there does not appear to be any increments between 0 and 100 %, yet the file has been reindexed.) D - Workaround - Ashton Tate suggests using the expression INDEX ON FIELDLIST + ' ' TO FILENAME where one blank is added to the fieldlist. (UGH! We are almost back to the old bug of multiple's of 4.) NOTE: In my discussions with Steve at AT, he said that the Workaround presented in D (Above) is not effective 100% of the time! - - - APPEND FROM 1. When appending some fields from a large file to a small file , the index of the small file sometimes grows to be twice as big as it should be. SEEKS on the appended file operate properly. Fixes, Work-Arounds, and Comments FIX - REINDEX will reduce the index file size to its proper size. (I wonder what this has to do with the indexing bugs? - - - Indexing A client added another record to a file indexed by last name, and the program could not find the record, despite trying a REINDEX with SET TALK ON. The name was ROTH, and there were other ROTHS in the file which could be found. Fixes, Work-Arounds, and Comments Steve at AT says there are 60 + documented indexing bug reports and AT is having considerable difficulty finding similarities or common threads among the reports. He mumbled an opinion that there would be a revision but said he had no idea if and when or what or whatever would be the update policy. Since my client actually preferred to be able to do a lookup using last name and first name I solved my indexing problem by the following: INDEX ON TRIM(LNAME)+', '+LEFT(FNAME,1) which worked. That is, SEEK 'ROTH, B' is found and SEEK 'ROTH' produces the first ROTH in the database. Page downs find the previously missing ROTH whether I SEEK by last name only, or if I SEEK on Last name,+first name, first initial. Note that this fix or workaround changes the length of the fields used for indexing. Thus, in this particular case, Steve's claim that adding a space to the index field isn't always effective, worked for this particular combination. Note also, that Steve reiterates that the old multiple of 4 bug is gone. UNFORTUNATELY, I think that it may have been replaced with a multiple of a random number where the multiplier may be random also, and where the fix may involve the addition of random lengths of random characters! (Actually, it ain't all that bad, folks, I'm just a wee bit scared.) ******************************************************************************* TO PRINT SET PRINT ON 'Printer Not Ready' A note in the Data Based Advisor's Feedback column (a nice magazine) states that a TO PRINT command may produce a Printer not Ready Message and that REPORT FORM TO PRINT and SET DEVICE TO PRINT may not work for some serial printers. The Editor comments that SET PRINT ON caused problems on some computers with serial or parallel printers. Fixes, Work-Arounds, and Comments Try ON ERROR DO FIXNAME where FIXNAME is a procedure program that includes a RETRY statement. The DBA Editor reported that it fixed the problem on one computer with a parallel printer, but didn't work on another computer type which had a serial printer. I have been using this fix for some time and it has been working for me and my parallel Epson FX-286 without a hitch. ******************************************************************************* History Original message revised and Bugs 2 and 3 added on March 30, 1986. (RJS) Original message revised and Bugs 4 and 5 added on April 27, 1986. (RJS) Format revised, Indexing, Printer bugs, Notes added May 24,1986. (RJS) ROBERT SCHNIEBOLK GAITHERSBURG,MD CONSULTING TECHNOLOGIES 301-840-0360 DB3, dBase 3, DBASE III Plus etc and all combinations are, of course, the copyright of the Ashton-Tate Corporation, and if I could figure out the proper way to write it, I would use that form. AT themselves seems to use several different variations. * EOF --- *