Author: Rick Gretter, Ward Dorrity
Editor: Ward Dorrity
Subject: Paradox Net and Lock Files
Date: December 15, 1987
Paradox Net and Lock Files
Few software products work as well as Paradox does in a network environment.
The fact that Paradox allows multiple users to simultaneously access, edit,
report, and query the same data base file without writing code to do so is
nothing short of amazing in light of competing products' behaviour under the same
circumstances. Developers of software for multi-user system environments all
face the same problem: that of controlling various users' degree of access to
files. Paradox allows one user to control other users' access to tables and
other Paradox objects by placing locks on the files and objects in question. The
AI techniques employed by Paradox place locks without any action on the user's
part to allow concurrent use of tables when possible, and will prevent access
when loss of data might result.
We will briefly examine Paradox's control of file access. We will also
explore a few loopholes that allow users to inadvertantly evade Paradox's
locking and look at ways to plug those loopholes.
.NET and .LCK Files
Every network operating system incorporates facilities for controlling
access to files. Paradox doesn't actually make much use of these facilities.
Instead, it uses two special file types of its own:
o A "net file" called PARADOX.NET contains the user name, product code (for
Paradox 386), and other control information for each active user. This file
is session-specific. When the first user fora particular Paradox session
starts Paradox, Paradox tries to locate the .NET file in its previously
designated location; the .NET file is created if doesn't already exist.
o Lock files, identified by their .LCK extensions, tell who is using a
directory of file, what kind of operation they're doing, and what operations
initiated by other users can be allowed to run simultaneously.
Paradox uses operating system facilities only to control access to the .NET
and .LCK files. These lock files are accessed "behind the scenes" only by
Paradox, NEVER explicitly by the user. Paradox uses these files to control
access to tables and other Paradox objects. DOS 3.1 contains the necessary
operating system support, which makes it easy for Paradox to run on a variety of
Paradox distinguishes local from shared drives and doesn't bother to write
lock files on local (private) drives. On a shared drive, a lock file is used to:
1. Mark a private directory, so no-one else can make it their private or
2. Mark a working directory, so no-one can make it their private
3. Lock a table, recording who is using it and how, so conflicting use by
other users can be prevented.
5. Lock a family member, for the same reason (but note that certain types
of locks on tables are strong enough to prevent access to their
families as well).
6. Lock an individual record within a table, if the user is in CoEdit
Because each lock file is written in the same directory as the files it
controls, Paradox's locking scheme is decentralized. This allows good
performance and minimizes the chance of catastrophic damage to lock files.
PARADOX.NET File Particulars
Most of the difficulties associated with the PARADOX.NET file stem from
improper placement of the .NET file at installation or system update time. Both
the NINSTALL and NUPDATE routines will ask for the location for PARADOX.NET. In
order to answer this question correctly, some advance preparation is necessary
and you must understand your network. In particular, a thorough understanding of
the differences between physical and logical drives is essential in order to map
your users to the appropriate directories.
Sometimes, problems will only become apparent when a user attempts to login
and use Paradox. Logging in as a supervisor or superuser (which you must do in
order to install Paradox on a server) can mask errors in setup owing to the all-
encompassing access rights that go with supervisor status. As a supervisor, you
can do pretty much anything you like - only trouble is, what works for you as
supervisor may not work at all for a regular user. It is important to remember
that the location of the PARADOX.NET file must be specified from the point of
view of the user.
It is assumed that all users have been properly linked or mapped to the
appropriate drives/volumes/directories, and that each user has a private or home
directory of their own. You must be consistent in the way you do this. For
particulars, refer to the Installation Overview section in the Paradox Network
Administrator's Guide. Let's examine some of the more common problems.
"Can't lock PARADOX.NET"
If Paradox can't write an entry in PARADOX.NET when it is started, it
displays the message "Can't start Paradox: unable to record lock/unlock\PARADOX.NET" and returns to DOS. This problem is usually not hard to
solve. Installation and configuration mistakes that can cause it include these:
o The location of the .NET file might be identified incorrectly. For
instance, assume that the shared data directory is G:\APPS\PDOXDATA. If
your users are mapped to this directory as F:\, then the location of the
.NET file should be specified as F:\, not G:\APPS\PDOXDATA.
On some networks that allow non-dedicated servers, PC LAN in particular, the
user on the server must supply physical names for directories while the
workstations use logical names. For example, the workstations may know the
location of PARADOX.NET as "f:", but the server user (for whom this is a
local directory, not a shared one) must call it "c:\pdoxdata". From what we
have said above, it is clear Paradox can't allow this. The solution is for
the server user to equate "f:" to "c:\pdoxdata" using the DOS SUBST command.
this is documented in the Paradox Network Administrator's Guide. (Don't
worry about the statement in the PC LAN User's Guide that you cannot use
SUBST on a network; this particular use is safe.)
o PARADOX.NET might be placed in the PARADOX2 directory, which is a read-only
directory, rather that in PDOXDATA, which is read-write.
o Users may not have the necessary rights to the directory containing
o A workstation user might have loaded network software, but not logged in.
Although a single-user copy of Paradox can run without a network, it will
not run on a machine connected to a network if it cannot get to the .NET
o The first user to login may use Tools/Net/SetPrivate to set the shared data
directory to which they have been mapped as their private directory,
effectively barring anyone else from using it.
More than one PARADOX.NET File
Users sometimes see a message like " controlled by .NET in
(your .NET is in )" when they try to change directories or use a table in
another directory. This means that Paradox is trying to write a lock file to
control a file or directory, but finds that another user is already using the
file or directory. Moreover, the other user is described in a different
PARADOX.NET file than the one the current session is using. This in itself is
not a problem; in fact, we recommend using more than one .NET file in some cases
in our Runtime manual. However, each net file must have exclusive use of any
directory in which it places lock files. When users try to violate this rule,
the message above tells them why they can't proceed.
Situations may arise when people see this message even though they don't
intend to have more than one PARADOX.NET file. The difficulty here is that the
location of the .NET file must be specified when Paradox is installed, and it
must be specified using the logical name by which network users will know it
after their links are established. So it is easy to make one of several
o A user installing Paradox on a workstation but planning to use network
files might supply the wrong location for the PARADOX.NET file.
o On 3Com or PC LAN, where the location of the .NET file will usually be
specified just as a drive letter, a user might link the wrong directory
to that drive.
In either case, Paradox will create a PARADOX.NET file in the directory it's
told to use if it doesn't find one there.
.LCK File Particulars
We have said that Paradox puts a lock file in the same directory that
contains the file being locked. As a result, network users must have write
access to any directories from which they wish to access tables, even if they
only want read access to the tables. (If necessary, the Protection Generator can
be used to control their access.) Paradox usually gives a clear message, like
"Access denied to directory", in cases like this. It is important to realize
that methods of assigning access rights vary from network to network, and some
networks offer many options, so it is difficult to generalize here. If a user
sees error messages involving lock files, it is wise to check what access rights
We have already discussed non-dedicated servers, but more serious problems
concern .LCK files. When Paradox is used on a non-dedicated server, the
server's hard disk looks to that Paradox session like a local drive. As a
result, Paradox doesn't write lock files or look for lock files that other
Paradox users on the network have written. Users on other workstations do "play
by the rules", of course, but that is really not good enough. For example, if
the user at the server is editing a file (without writing the appropriate lock
file), a user at a workstation won't know the file is in use and may also edit
it. At best, only changes made by the user who hits Do_It! last will be saved;
at worst, the table will be corrupted.
This problem can occur on any network that allows non-dedicated servers: PC
LAN, Tapestry, LanLink, Alloy's PC Slave, ViaNet, 10-Net (if Paradox can run on
it's servers), and others. The solution is to start Paradox with the -SHARE
command line option, which tells Paradox to consider what looks like a local
drive to be shared. Example: PARADOX2 -SHARE. You might consider writing a
batch file or INIT script to force people using Paradox on non-dedicated servers
to use the -SHARE option.
Paradox can't detect that there are two PARADOX.NET files: On many
networks, such as 3COM and PC LAN, users can link drive names to symbolic names
for directories, and never know the path from the root to those directories. For
example, when "f:" is linked to "pdoxdata", a user doesn't necessarily know the
path to "pdoxdata". Unfortunately, neither does Paradox. As a result, the rule
we discussed above - that when one PARADOX.NET is using a directory, all others
are locked out - can't be enforced on these networks.
What happens instead is this: The first person to use a table writes a .LCK
file normally. If another user with a different PARADOX.NET uses the same table,
his or her copy of Paradox sees the lock file but (since it doesn't own it)
thinks it is obsolete and discards it. This is likely to result in "Unexpected
condition: missing .lck" for at least one user, but might also lead to
If users on these networks want to run with more than one net file, they
must install several copies of Paradox, and use our installation procedures to
supply locations for the PARADOX.NET files that Paradox will recognize as
distinct. For example, interactive Paradox users might link their .NET file in
"pdoxdata" to "f:" while people using a Runtime application use a .NET file in
"prundata" and link "prundata" to "g:". However, it is better to use only one
.NET file until there is clear evidence that performance would be improved by