PLEHN%mit-mc@sri-unix.UUCP (06/09/83)
From: Allan D. Plehn <PLEHN@mit-mc> I found the following on a local RCPM: /////////////////////////////////////////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ Listing file DBASEHNT.DOC ----- INSERT HINT ----------- donated by Charlie from Orange Bytes Newsletter A bug has been detected useing the Insert command. It can result in the loss of data record if a carriage return is issued at the wrong time. (Tate knows about it but no solution yet.) So they are recommending that you do not use INSERT and INSERT BEFORE. Case in point, C.J.Thompson wrote that if you have issued the Insert command, after indexing to some intermediate record in your database, you are presented with the standard data input screen with the cursor in the first position of the first field. If you enter data at this point, everything seems to work as advertised. But if you should happen to enter a carriage return (thinking perhaps, to move the cursor to the second field), you are dumped out of the Insert mode only to find that the record count in your database has been incremented by one. Further insp`,W{on reveals, however, that the 'plus one' count is the result of two events; (1) the record following the intended insertion point has been triplicated, and (2) the next record has been deleted. And evidently, not by a "*" but 'all gone'. ------- Goof Hint ------- by Charlie for Charlie I was going to update a members information in my Name/Address database when I accidently entered a CONTROL CHARACTER UNKNOW into my file and it got written to the DataBase. I had 272 records in my DBF file but after that goof I got a OUT OF RANGE error after 24 records. After two lousy hours of research and trial/error I finally got it back on track. In my efforts, I learned a lot about things I really have no need for but what can I say, maybe some day. Anyhow, nothing worked, either in the DBF or NDX until (1) I added a new record (2) erased the NDX and then (3) INDEX again. It seems to be O.K. now. The error evidently changed the total record stored somewhere (I never found out where) but the 272 records was always in the DBF file. ---- Local hint (from Dave)-- When you use GET and the 1st field is a numeric it'll probably crash, if character it's O.K. (at least for him it did) Safety hint-- After working on your DBF file and you want to use PACK. Be sure to exit first ,to force a write to disk, then re-enter to do your PACK operation. Some locals have lost their data otherwise, but why hasn't been pin-pointed yet. FINI for now /////////////////////////////////////////////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ We use dBase rather intensively at my place of employment and additional bugs have been noted, as follows: a) If the CASE statements are nested to more than two levels the program will crash. b) If two files are open at the same time, a PRIMARY and a SECONDARY, SET LINKAGE ON command will crash the program and cause the infamous "BDOS Error on Drive xx" error message, with the xx being a non- existant drive. These two bugs occurred consistantly on both the eight-bit and sixteen-bit (CP/M86) versions of dBase II. I would be interested in hearing of fixes or new releases of dBase II that would take care of these bugs. Al Plehn <PLEHN@MIT-MC>