Mark Amanns
12-13-02, 13:59
| I have dBase 5 for DOS and a Novell 5 network for up to 110 users. I have noticed 3 kinds of errors happening more often now, often with tables opened exclusively, not shared: (1) The most common is that invalid characters get stuffed into records, usually the newer ones. The worst is where the ASC(1-27) control characters get into fields that are indexed, then the index is bad. The data has to be fixed or removed, and then PACKed (since even deleted records can mess up an index). Since some of the data is just offset right or left, it looks like the buffers are getting scrambled. Other times it looks like part of the browse screen itself is there in the record, including the vertical bars! On rare occasions I've even seen the text of a report that had been sent to the printer stuffed in the middle of a DBF! I wonder if part of the problem is that much of the original code has the users editing the actual fields on the screen or by BROWSE. Perhaps using memory variables to add/edit may be better, but is not feasable to do in most cases. (2) Appending a record to a table can end up with the RECCOUNT() not matching the actual records. We now detect this by LISTing one of the table's fields with the console screen off, then comparing the "last" record's number (now at EOF() to the record count plus one. For example, you can LIST 50 records, but RECCOUNT() reports 60. The "missing" records really are there. If you GOTO 55, then DISPLAY or "?" the fields you see the data, but BROWSE says "End of field encountered". I used to PACK the tables. Now I rename it to a temp name, recreate the table, and APPEND in the old records. By doing this I can salvage some of the newer records where the header says there are fewer records than there actually are. Added note: I just scanned what was written to the disk and saw what seems to be index code in the middle of a record or two. Somehow the index data is getting dumped into the table. These should be discrete, separate file handles, so something is screwy here. Why would data from one area be written into another file handler area? (3) Similar to above, except the records appended never really append. The file size never enlarges but the record count does. PACKing the table (and REBOOTing the workstation is a must!) seems to fix this. But I've noticed that some tables are repeatedly getting corrupted this way by only a few certain users. (The workstations are NOT identical.) And once they corrupt one table, they can then corrupt some (but not all) tables opened later doing the same functions. This has been a real problem in recent months. Since the Novell 5 network does compress some files, we made sure that these DBFs never compress anymore. Looks like there may be fewer data errors now, but they still happen. Even once is too much! Checking all DBFs every night catches these errors, but this cannot continue. HELP! |