|
|
|
|
How to Troubleshooting Database Problems |
|
Introduction
|
Your database can have bad data without the database being damaged. This leads us to a few common misconceptions about Clients & Profits that are worth clearing up. How do I know my database has been damaged? Depending on the seriousness of the damage, Clients & Profits shows error messages whenever it detects a problem. The program constantly checks the integrity of your database as you use it. If its built-in error checking (the “Quick Check”) finds a problem, it shows an error message such as bad pointer, bad header, etc. These messages shouldn’t be ignored since they indicate something’s wrong that can’t be worked around. In the case of most errors, you can still use other parts of the database. But don’t be fooled, because these problems don’t go away. For example, if you get a bad header warning when saving a purchase order, other users on your network won’t stop working. But the problem is there for anyone else trying to add a PO. So when a database crashes, you must find and fix the problems immediately or you may lose the entire database permanently. Damaged data does not fix itself, and will worsen over time.
Since minor forms of data damage will not cause a Quick Check error, always be aware of inconsistencies in your database. Make sure every user knows to report any odd behavior or error messages to the system manager. Changes in response time, costs or billings that disappear, changes not being saved, etc. can be an early indicator of data damage. By addressing this situation early, even before getting a damaged data message, you will be saving yourself and your company from a more severe problem. First Learn What Went Wrong Be especially aware of error messages if you’re on a network. No error should be ignored, since infrequent errors can accumulate into a big (and possibly unrecoverable) crash. Users should report errors promptly, since they are often the only way the system managers know there’s a problem. Get the facts — questions to ask What was the first error message? Discovering the original error message gives valuable clues to the cause of a problem. Since one error usually leads to more errors, later messages may be different—and possibly misleading. Is the problem reproducible? Can the user cause the error to happen again? If not, then it was probably a temporary problem that isn’t as serious. But if the same action (like printing a job list) won’t work repeatedly, then the database is seriously damaged. What was happening when the problem occurred? If an error occurred during batch posting, for example, we know that the user’s computer was saving records. Since saving involves the hard disk, it points to drive problems as the cause. But if the user’s computer was idle and the system crashed, the hard disk probably wasn’t in use at the time—pointing to some other cause. What were you working on just prior to getting the error? Try to determine just what had been happening in the hour prior to the error. If things suddenly got slower prior to the error, for instance, this could indicate a network communication problem that was building up until it finally snapped. Does the same problem happen to everyone? If a report won’t print on your computer, for example, can the report print on someone else’s? If so, this means there’s a problem with your computer, and probably not the database. If the same problem happens on any computer you choose, then it’s a database problem. Does the problem occur on a local database? If the database were copied from the server to a user’s hard drive and opened, does the problem occur? If not, that’s an indication of a server or network problem. Was there a recent change in the server, network, etc? It’s not uncommon for someone to change some hardware or software and unknowingly affect Clients & Profits. If so, the previous configuration will need to be restored and evaluated for compatibility.
Next Page: Database Myths |
|||