What can cause a database or table to “break,” anyway?
A database or table is usually a very robust and reliable structure that gives years of service for dozens of users with nary a hiccup. So... what can cause a database or table to “break down,” and what can you do to prevent it?
Physically broken or corrupted files (and file-systems):
The “file system” is the physical structure that Microsoft Windows® or MS-DOS® uses to keep track of how and where your data is actually stored on the hard drive. As you probably know, this structure can become broken, and Windows will generally try to “repair” it automatically when you reboot. (The process we are describing here is not something that is done by ChimneySweep, but rather by some other tool.)
What you may not know is that files which are “open” for long periods of time, and especially those that are opened by multiple network users at the same time, are much more vulnerable. Database files, of any kind by any vendor (including Microsoft), unfortunately fall into both of these categories.
In the process of “repairing the filesystem,” files that were open at the time of the failure might become broken into multiple pieces. Only one piece is filed under the original name: the “other pieces” might wind up as files with names like "FILEnnnn.CHK," or as “a file with a number for a name” in a directory with a name like "lost+found." (And as it happens, that's really all that the filesystem repair tool could possibly have done, because it had no way to know where those “other pieces” belonged, nor what they might have originally been named.)
Trying to recover from this situation is a very advanced technique (some would call it “voodoo” ...) which ChimneySweep does not attempt. If this happens to you, you're going to need to have a backup... which, of course, ChimneySweep can help you make.
Unexpected application failure:
When an application fails in the middle of an operation, the database may be left in an inconsistent state. Repairs from this situation are comparatively simple.
More problematic is when the computer fails, such as due to a power-failure. This can cause damage to the structural integrity of the hard drive itself.
Network locking and cacheing problems:
The mechanisms which control access to a single table by more than one network user are designed to be robust and reliable, but they can break, especially if many different versions of Paradox® or BDE™ are used on the same network at the same time. Serious problems can also occur if operations are attempted by a user which is logged-on directly to the computer upon which the database files are stored, if the BDE LOCAL SHARE setting on that computer is not "TRUE."
Network file-systems rely upon the notion of “cacheing” (storing information temporarily in your local computer's memory) to achieve acceptable performance. It is very important that all of the computers on your network are using the same version of Microsoft Windows™ so that all of them will be using the same networking software.
More-recent versions of Microsoft Windows offer a feature called “opportunistic locking” that can cause unwanted problems with database files. (The clever-idea that they try to take advantage of is that “I don't have to bother locking this file if I know that only one network user is actually using it.” But that's not such a clever idea in the case of database files, which are constantly being opened and closed.) Well-intentioned though this advanced feature may be, opportunistic locking can slow things down quite considerably when used with Paradox database files, and they can introduce timing problems that can lead to file corruption.
Timing problems, anti-virus software, undiagnosed hardware problems:
To achieve good performance, network file-systems rely upon the presence of fast, reliable communication between the computers. This can be affected by various network problems which, due to the redundant nature of networking hardware, might go unrecognized for a very long time. (In other words: no, “the mere fact that all the little lights are blinking like they should” does not mean that “all is well!”) Serious disruptions can also be caused by slight, brief fluctuations in electrical power.
If your network appears to have “suddenly” become unstable and unreliable, suspect a hardware problem ... and find a reputable local hardware specialist with access to the right diagnostic equipment to help you troubleshoot it. You can't just solve these problems by guesswork and intuition.
“Anti-virus” software can be a very serious problem, especially if it is set to the usual setting of “scan all files when they are opened.” First of all, database files cannot contain viruses anyhow. Second, they get opened and closed constantly! Anti-virus software can bring your database, and your network, to its knees.
“What changed... recently?”
Your best assistant in guessing what might have gone wrong is to ask yourself what changed. To this end, a maintenance log or diary (written down with pencil-and-paper and kept in a convenient notebook) can be a great help. Take careful notes of what you observe, what you did, and what happened next. Record the date-and-time next to each entry and be sure to write very legibly. The process of writing things down is, itself, a good way to help you stop and think. The (hand-)written record is a very valuable reference for spotting patterns and trends.
What if, actually, it isn't “broken?”
It is well worth remembering that many situations can turn out to be a “red herring.” You think ... you assume ... that you understand the true nature of the problem, but your assessment turns out to be misleading. (You have, quite without intending to, jumped to a conclusion.) Before concluding that your database is truly broken, check some possibilities such as the following:
- Is the problem being experienced by more than one user (if applicable), in exactly the same way?
- Are you very sure that this workstation really is (still) logged-on to the network?
- What happens if you log-off this workstation and log on again? What happens if you log-on as someone else? What happens if you log-on as the same user, but on a different computer?
- What happens if you shut down the workstation, all the way to power-off, then wait about ten seconds and power it on again?
If the problem is truly with the files that make up the database, then the symptoms will be both consistent and repeatable. In other words, every user which attempts to do a certain thing will be presented with the same sort of errors, even after they have logged-off and logged-on, even after they have turned off their computers and turned them back on again, and so-on. ChimneySweep will probably be useful in resolving problems such as these. On the other hand, if the problem appears to be specific to a particular computer, to a particular network user, to a particular area of the network, and so-on ... if it is experienced by some users but not by others ... then the true source of what you are seeing might well be something that is entirely unrelated to the sort of thing that ChimneySweep can be expected to fix.