Paradox data corruption problems
This article deals with the well known problem of file corruption when using the BDE/Paradox tables on a network.
This article is not about a Paradox system that doesn't work at all. If you can't get your system to work at all this is not the article for you (though some of the links at the bottom may help.)
Paradox corruption typically involves a system that works, and works reliably; but then periodically breaks leaving corrupted database tables. The corruption typically appears as either corrupt tables, or index files being out of date. Occasionally you may get faults where recently added records are missing.
Now some bad news. It only takes one machine on the network to be misconfigured for such problems to appear. And some more bad news, many of the faulty settings are the defaults set by the OS or by the BDE. That means that adding a new machine to the network or re-installing the OS or the BDE is quite likely to make the problems re-appear.
The root cause of all these problems, is the caching of data between the user program and the hard disk where the data is stored. This has two effects. If the caching process is faulty it can directly cause corruption. Also, if some other problem occurs: a power failure, the user resetting the computer or a software crash; then it increases the likelihood of data being lost or corrupted.
There are at least three places where caching occurs in a typical BDE/Paradox network setup:
- (a) In the BDE on the user's PC,
- (b) in the OS on the user's PC,
- (c) in the OS on the PC where the data resides.
Caching within the BDE is affected by two issues. Firstly, that of how 'LOCAL SHARE should be set (see below). Secondly, problems of whether the BDE's own cache is getting flushed or not (see below).
Caching by the OS at either the user's machine or the file server is dependant on the version of the Operating System being used. Each different version of Windows presents it's own problems (see below).
LOCAL SHARE
This seems to cause more problems than anything else. The biggest problem though, is trying to find out what this setting actually does. The explanation given by Borland in the BDECfg help files seems to directly contradict what is said in other sources; including other Borland documentation. In addition, the word 'LOCAL' is downright misleading. To Borland, 'LOCAL' means a disk visible on the file system including mapped network drives.
Here is my understanding of what LOCAL SHARE means:
If LOCAL SHARE is FALSE the BDE believes that it is the only process that is going to open the database tables. This means the BDE can give higher performance by omitting certain tasks.
So setting LOCAL SHARE to FALSE is faster but more dangerous. Also, there are situations where sharing is happening even though only one user is using the tables. This can happen when more than one copy of the BDE gets loaded, typically where the user is running both a 16 bit and a 32 bit program.
Conclusion: set LOCAL SHARE to TRUE and curse the people at Borland for not making this the default setting.
Flushing the BDE Cache
This is perhaps a programming issue rather than one of configuration. In normal use, new or modified records are first saved to the BDE's own cache. Then, in the background, records in the cache are written out to the hard disk. This is normally known as 'write behind' caching.
However, this writing to the disk in the background doesn't happen automatically. At least not in versions of the BDE before version 4 (Delphi 3). In a Delphi program using older versions of the BDE, you need to add code to make the BDE write to disk.
There is another problem which occurs if the user closes down Windows while a Delphi/C++Builder program is running. Under normal circumstances when a program is closed any DLLs that are no longer required are unloaded from memory. This also means any close down (finalization) code in the DLL gets run.
Under normal circumstances, closing a program will unload the BDE. The BDE will flush the cache first before it gets removed from memory. However, when you close Windows itself this doesn't happen. Windows says to itself, "we are closing down, no point in cleaning up". This has the undesirable side-effect that the BDE does not flush it's cache under these circumstances.
This problem can be solved, by coding. Or you can try and train the users to close down the applications before closing down the PC.
Windows 95/98/ME Systems
There are known problems with earlier versions of the caching & network redirector drivers in Windows 95. This probably does not affect Windows98 or WindowsME systems.
Opportunistic Locking (WinNT & Win2000)
Windows NT implements a form of Opportunistic Locking. This is known to cause problems with some database systems. The exact behaviour probably depends on whether all machines on a network are running NT or whether you have a mixed network of Win95/Win98/Win NT machines.
Windows 2000 has similar features but the locations in the registry of the relevant settings has changed.
Novell Netware
Novell have also implemented an Opportunistic Locking system which may need to be disabled.
- Overview
- What it does
- Download BDEChecker
- Paradox data corruption
References, resources and useful links
Note: most of these links are now broken. In fact, I am not sure that much of this information is still available on-line.
The Delphi Magazine: Paradox file corruption
An extensive article by Brian Long detailing various causes of paradox table corruption. The article includes Delphi code that can be incorporated into your applciations, either to fix settings when run, or to abort the application if settings are invalid.
Borland Technical Info Sheet TI3342
Borland TI Sheet describing causes of paradox table corruption.
http://community.borland.com/article/0,1410,15209,00.html
Borland Technical Info Sheet TI247B
Borland TI Sheet explaining how to setup the BDE on a network.
http://community.borland.com/article/0,1410,15247,00.html
Borland Technical Info Sheet TI2953
Borland TI Sheet shows how Delphi programmers can prevent the BDE from cacheing data indefinitely. Probably not needed for newer versions of the BDE.
Borland BDE Developer Support pages
Borland's home page for the BDE.
http://info.borland.com/devsupport/bde
Microsoft KB Article 148367
Microsoft KB Article detailing problems with vredir.vxd redirector. This article also includes a link to download an updated version of this driver if it is needed.
http://support.microsoft.com/support/kb/articles/148/3/67.asp
Microsoft KB Article 129202
Microsoft KB Article explaining Opportunistic Locking under WinNT.
http://support.microsoft.com/support/kb/articles/129/2/02.asp
Microsoft KB Article 296264
Microsoft KB Article detailing giving configuratin details for Opportunistic Locking on Win2000 sytems.
http://support.microsoft.com/support/kb/articles/296/2/64.asp
TUtility Component
A useful component for Delphi programmers that allows you to verify & repair Paradox tables
