Database repair doesn't occur in a vacuum. Database files are usually
shared by many workstations at a time. ChimneySweep must therefore be very
careful to ensure that the changes it's making will not conflict with
anyone else's.

When ChimneySweep processes any table file, it attempts to "lock" it in not
just one but two different ways:

(a) by requesting a BDE full table lock ... this is the same sort of
thing that Paradox for Windows, or Delphi, attempts to do when it tries to
access a table "normally." This is a "high-level" mechanism.

(BDE = Borland Database Engine; the database engine used by any Paradox for
Windows or Delphi program, or by ChimneySweep itself.)

(b) by attempting to open the table-file, as an ordinary DOS or Windows
file, using the "exclusive" share-mode. This is what any application might
do when working with a potentially-shared file, whether or not it's a
database application. So, this is a "low-level" mechanism.

-----> For issues relating to "(a) BDE full table lock":

The Paradox file-locking mechanism is controlled by a ".LCK" file and by
the ".NET" file. There are one or two ".LCK" files in any database
directory used by any BDE application. There is one, global, ".NET" file
which will be found at the location specified by the "NET FILE DIR"
configuration setting for BDE.

** The "LOCAL SHARE" setting should be TRUE for all workstations AND the
server.

One of the options specified for most ChimneySweep jobs is that it
should "attempt to clean up locks," which it does by trying to delete
the .LCK files as it encounters them. If no one is using the lock-file
(there are no tables open), removing the .LCK file will succeed ... and it
will clean-up any issues related to, say, a corrupted .LCK file because the
file will be automatically re-created on demand. But, if the file can't be
deleted (e.g. because it is in use), you'll see that reflected in the
last-job-output.

A more subtle possibility is that the BDE session used by ChimneySweep, on
whatever computer you're running it on, is mis-configured; it does not have
a NET FILE DIR setting or the setting on this computer doesn't agree with
the same setting on all the others. That keeps the locking mechanism {(a)
above} from working properly. Again, you'll see that in the detailed
last-job-output.

-----> for issues relating to "(b) Windows file lock":

A possibility that can occur here is a "ghost lock." When a workstation
computer is turned on or rebooted, it broadcasts the fact that it was just
rebooted to anyone on the network that may be listening .. such as the
file-server this computer might have been logged-on to. The server will
know that, "if that computer says that it's being rebooted, it is not
logged-in to me anymore." The server will close any file-handles and clean
up any (file-level) locks owned by those sessions.

But, sometimes, that doesn't happen. A "ghost session" remains. The server
administrative control-panels, when asked for a list of open files or
sessions, will show that the files are still open by the "ghost." This
prevents ChimneySweep from being able to open the files exclusively.

=====

Here's what to do:

(1) First, confirm that the BDE configuration on this computer is correct.
LOCAL SHARE should be TRUE, and the NET FILE DIR should be properly
specified.

(2) If you can, physically power-off the server computer and also the
computer upon which ChimneySweep is running. Wait 10 seconds and power-on
the server again. Once the server comes up, power-on the workstation in the
same way.

(3) Run an exhaustive filesystem check on the server. Filesystem
corruption can be subtle.

----
ChimneySweep(R): Fast(!) table repair at a click of the mouse!
http://www.sundialservices.com