Back to Manual Table of Contents
MySQL is definitely one of the most stable database programs available, as proven repeatedly in testing by a wide variety of organizations. But computer hardware and software is not perfect, and data corruption can happen to anyone. Even if you never have a corruption problem, you should know how to prevent, identify, and fix any problems that might arise.
MySQL 4.0.12
This version of MySQL had a bug which we were originally unaware of. The bug caused an occasional corruptions. A typical dental office would run into this issue approximately once every 4 months, and might lose one procedure or patient address about half the time the issue occurred. If you have a corruption, first repair it as described in the rest of this page. Then, upgrade immediatly to MySQL version 4.1.10 as described on the MySQL Update page.
Prevention
Make backups. That way, if something does happen, you can simply restore the
backup. Of course, this is assuming your backup is not corrupted. For this reason,
you should keep a variety of backups. If the one from yesterday is damaged,
you could use the backup from the day before yesterday, or even the one from
last month. That's better than losing all your data. See the section on backups
for ideas on how to make sure you have good backups.
Run antivirus software and use a firewall. Viruses can cause damage to your data.
Never turn off power to any computer without shutting down properly through the Windows menu. You should have an Uninterrupted Power Supply on the server to prevent immediate shutdown in a power failure. Use good quality surge protectors on all computers.
Make sure you have good hardware, quality network wiring, and that you regularly update Windows using Windows Update.
Try not to use your server very much for anything other than sever purposes. If you load lots of other programs onto your server, and then it gets used heavily, it will definitely tend to crash more. The more the server crashes, the higher the risk of your data getting corrupted.
Identification
There is a built-in tool that checks the files
in your database to ensure that they are not damaged. This should be the first
step if you suspect corruption. In the Main Menu,
under Tools | Misc Tools, select Check Database Integrity.:
The last item is important. When you run it, it will tell you if it finds any problems, and it will give you the option to repair. If you do repair a corrupted table, you must follow up by analyzing the repair log. You can analyze the repair log yourself or send it to us for analysis. The program will attempt to print the repair log, but if it cannot, then you will need to open it manually. The location of the file that will have been created is usually C:\Program Files\DentOffice\RepairLog.txt, but it might be slightly different depending on where you initially installed the program. Click on the file, and if prompted, use Notepad to open it. You should see something like this.
Select File | Print to print out a copy. You can analyze this file yourself using the following guidelines, or if you have any questions, you can fax it to us at 503-485-5202. If you do fax it to us, please be sure to include your contact information so that we can reply back to you.
In the example above, three tables were repaired with no problems. You can see the the first table had the number of rows changed from 6 to 20. This is because of the way the files are organized. Every table in the database is actually comprised of 3 files, the data file, an index file, and a schema file. The purpose of the index file is to improve the speed of access to the data with pointers. If the index file gets damaged, it does not mean that your data is damaged. The table is corrupted only in the sense that it will not function properly because the pointers are pointing to the wrong locations. The index file can be rebuilt by the MySQL program without actually touching any of your data. So, in the first table, the index file was corrupted. It thought there were only 6 rows in the appointment table, when in fact there were 20. The index file was rebuilt and now shows the correct number of rows. The same thing happened with the third table. The second table had a minor unspecified error.
If you see any messages other than those above, we will need to see them so that we can include them on this page. Especially important would be any errors that described the deletion of a row or a decrease in the number of rows. If a row is deleted, it is VERY important for us to help you because a missing row can cause malfunctions within DentOffice, and is more significant than just the missing data.
Followup with More Prevention
If you need to frequently repair tables, it is a serious issue which should
be addressed. Make sure you are using the correct version of MySQL and work on the areas listed under prevention.