Working with damaged Alpha FOUR (and Alpha/three) database files This document is intended for you if you're faced with a potentially damaged database file and you want to try to save as much of the data as possible. This document will first go through what causes damage, then will discuss how to determine if the problem is actually with the actual data file and finally we will offer some suggestions on how to save as much of the data as possible. What causes damage to database files: Alpha FOUR uses the standard dBASE .DBF format but the files are stored just like other files on the disk and are susceptible to the same magnetic influences as other computer files. Database file problems can be as simple as misaligned records or as complex as a corrupted file header coupled with lost file clusters. The file header contains the structure of the database and lost clusters are fragments of the file that are missing. Below are a a few potential causes of database corruption: Corrupted disk space. The physical disk space where the file is stored may have become corrupt an this would obviously damage anything stored on this disk space. Quitting Improperly. The last person who used the database may not have quit the program correctly before turning the power off . This results in the file not being closed properly and may cause problems. To avoid this in the future simply make sure to always use the quit option from the main menu before turning the power off. Using a non-standard write cache. Cache programs are popular ways of speeding up your computer's performance. Write caching is a process of holding all disk write operations (saving a record, changing a record, etc) in memory. When a few write operations have been accumulated the write cache saves the bunch to disk in one shot. If the write cache program works in a non-standard way inconsistencies in the data may result. Reconfiguring and Global Updates will not cause corruption of a database file but are mentioned here because people sometimes incorrectly assume that the database has been corrupted when the only problem is that the data was changed in a way inconsistent with the intent of the user. Reconfiguring the database. Reconfiguring the database will not cause problems in and of itself., however reconfiguring a database is a permanent step. If you inadvertently make changes and perform the reconfigure with changes you do not want it will make these changes permanent. During a reconfigure the database is actually copied to another temporary name with the requested changes. The original database is then erased and the new database is renamed back to the same name as the original. Global Updates. Like Reconfiguring the database, performing a Global Update on your database will not cause problems in and of itself., however if you perform a Global Update against the database and the expression logic is inconsistent with your intent the result will be different from what you expected. A Global Update is permanent and once the database has been changed you will have to work with what is left in the fields to try to resurrect the field contents. How to tell if the problem is due to a damaged .DBF file: What may appear at first to be damage to your database file (.DBF file) may actually be damage to another "helper" file (such as an index, search, range, form, browse table, etc.). The data may indeed remain intact and be fully correct, but may be clouded by the layers of other files that the program uses to view the data. The first step is to determine if the data file is actually where the problem is. To do this you'll want to isolate the data file from anything that may cause it to appear different (layout, index, search list or range). Get to the Alpha FOUR main menu and retrieve the database in question. Press V for view and scan through the records. If you see a problem try removing any custom form you may be using to view the data. To do this while in view press O for "options", then C for "choose another form" and select the 0 (zero) form. When you return to the data view you should see the database on the screen, all the fields sequentially numbered down the left side of the screen. This is the default form and what you see here is your raw data without any custom Form at all. If this view (default form) appears different from the last view it indicates you were using a custom designed Form which customizes the way the screen displays your data. Now scan through the database. If the data appears to be OK now then the damage is most likely in your custom form and not in the database at all. Make any necessary adjustments to the Form layout before using it again. For more on Form layouts see Chapter 13 in the Alpha FOUR reference manual . If the damage still appears the next step is to remove any limiting range criteria such as "First" or "Last" limits or a filter. While in view, choose the default range by pressing R for ranges, F7 to retrieve a range then choose the 0 (zero) range. This is the default range and does not contain any limiting criteria (searches, indexes or filters). Because the range does not contain an index, the records will all be viewed in record number order (the default if no index is selected). If the damage still appears after selecting the default form and range then you can most likely assume that the database is the source of the problem. Once you determine that the database file is the source of the problem the next step is to try the following things to see if Alpha FOUR can resurrect the problem. What to try: Find your most recent backup of your database files. If you have a recent backup and are willing to reenter the records entered or changed since the backup was made, the simplest thing to do is to restore the backup and accept the few record losses. If you don't have a backup or aren't willing to loose the changes since the backup was made there are a few other things to try: Copy the database in record number order to another filename. Use the Alpha FOUR copy utility (under utilities) to copy the database to another filename. Make sure to use record number as the active index. After copying check the new database to see if everything copied OK. If copying does not work then you can try exporting the database (as a character separated ASCII file) to a temporary file then import back into Alpha FOUR (also as a character separated ASCII file). On both of the above options you may find that the database copies (or exports) only up to a certain point (defined by the record number) and then stops. This may indicate that the corruption is contained within a range of records but other parts of the database are fine. To rescue as much of the database as possible copy the good parts of the database into smaller files then put these good files back together into one database. You may loose the damaged parts but they hopefully only contain a few records and are unreadable anyway. Here's an example - Let's assume that the database is damaged from record 450 - 456. We don't know this yet but when we tried to copy out the database it stopped on record number 451. We can therefore assume that something is wrong starting at record number 451 and we want to copy out the good records up to and including 450. To do this copy the database again but this time change the range screen so that the "Last" record reflects the record number just before the end (450). The resulting database will contain the first 450 (good) records. Go back to the original (damaged) database and copy it again however this time set the "First" parameter on the range to 452 and leave the "Last" option at . If the copy immediately stops you know that record 452 is also bad and you should try again with 453 as the first record. Keep trying, incrementing the "First" record each time, until the copy actually starts copying out records. Once Alpha FOUR starts copying records, if it continues to the end you can assume that the damage was limited to only one segment of the database. If Alpha FOUR starts copying but stops at some other record you most likely have two or more damaged spots and should repeat the operation until you have copied out all the good records into separate smaller databases. After copying the good records into separate databases the final step is to put these back into one database. To do this retrieve the first of these smaller databases and use the Append command to append each of the other databases to this first database. This will simply add the records from each smaller database to the first database The result should be one database containing all the good records. You can then delete all the other databases (including the original damaged database) and rename the good database back to the same name as the original. Reoccurring problems...let us know! We are currently not aware of anything within Alpha FOUR that will cause data loss except for the improper use of the program. If you find that your data has been damaged and you can recreate the problem we are very interested in hearing from you with the specifics. We at Alpha take data integrity very seriously and make extensive efforts to ensure that your data is not put at risk due to anything within our control. However there are many configurations of software and hardware and there may be an obscure situation that causes problems that we had not taken into consideration. If you come upon a situation where you have lost data and can reproduce the situation please send a copy of your database with instructions on how the problem can be duplicated to: Alpha Software Corp. 168 Middlesex Turnpike Burlington, MA 01803 Where to go from here: If your efforts to save the data have thus far met with no results it could be that the header of the file is damaged or the file is too far gone for these things to resurrect your data. Hire a consultant. If the file is too far gone to be retrieved using the above suggestions, you may want to consider finding a consultant who specializes in working with damaged .DBF files (a.k.a. dBASE files). You will most likely be able to find one by contacting your local computer club or computer store. Do it yourself. If you would like to try your hand at more in- depth salvaging of .DBF files (recreating a damaged header for example) there are software programs available which may make the task less daunting. Comtech Publishing puts out a program called dSalvage and Norton Utilities version 6 includes a utility called Filefix.. dSalvage Norton Utilities version 6 Comtech Publishing Symantec Corporation P.O. Box 456 1021 Torre Avenue Pittsford, NY 14534 Cupertino, CA 95014-2132 (716) 586-3365 (408) 253-9608