BDE Checker
Many years ago, I wrote a small program to check an installation of the BDE and I wrote these web pages, mainly so I had all the information I needed in one place. The BDE is now a very out-of-date piece of technology. However, some people still download this program, so I will leave the program and the web pages here for maybe another year or two [May 2009].
Overview
There is a known, and long-standing, problem of data corruption when using Paradox tables on a network. Paradox tables are widely used not just by users of Borland/Corel Paradox but also by software written in Borland's Delphi & C++Builder languages. All these development environments share a common database engine - the Borland Database Engine or BDE. Click here for more information on Paradox data corruption and what causes it.
For some years, I've used a collection of hand-written notes to remind myself of all the things to check when setting up a new machine to run a Paradox application. Finally, I've got around to writing a small program (BDEChecker) to make this task a bit easier. This program includes checks to deal with Win2000 & Win XP systems.
BDEChecker performs a number of tests on your machine. These tests check various settings on your machine. These are settings that are known/believed to cause problems with Paradox data tables. For more information on the checks that BDEChecker does click here.
Click here to download BDEChecker.
What it does
BDEChecker performs a number of tests on your machine. These tests check various settings on your machine. These are settings that are known/believed to cause problems with Paradox data tables.
Typically you would put the program on a floppy disk or on some common network folder. There is no install program, just run it as it is. It is assumed each machine will already have a copy of the BDE on it. Then at each machine on your network, run this program. It is important that every machine on the network is checked. It only takes one rogue machine on a network to cause paradox data corruption.
To run the checks, start BDEChecker and then press the run button. A report on the checks run and the results should appear in the main window. You can print this or copy it to the clipboard and paste it into another program (e.g. A word document or an email program).
On Windows95/98/ME Systems
The program first checks some Windows systems DLLs (vredir.vxd & vnsetup.vxd). Older versions of these were known to cause problems. It also checks some registry settings relating to these services.
Then a number of registry sessions are checked relating to disk/file caching.
The program also checks some Novell Netware settings. These can be ignored if Netware is not being used.
On WindowsNT/2000/XP Systems
BDEChecker checks the registry to ensure that Opportunistic Locking has been disabled. The location of these settings is slightly different between NT & 2000.
The BDE
The program first checks the version number of the BDE. It issues a warning if the version number is older than the current version (version 5.2.0.2).
The program also notes the location of the .net file & the private folder. The .net file should be the same for all machines on the network.
Lastly the BDEChecker checks the setting of LOCAL SHARE. It should be set to true. This is the most important setting of all. Don't even consider setting it to any other value!
Download BDEChecker
BDEChecker is free. Download it - use it. Give it to your friends.
However BDEChecker comes with no warranty or guaranty of any kind, whatsoever.
Click here to download BDEChecker.
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.
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