You can use 'exclusive links' if you relink using code -
the relink wizard does not support this option.
If you use exclusive links, the BE database is opened
in exclusive mode.
If you open the BE database in exclusive mode, you
would expect it to be cached locally in the network
client cache, reducing network traffic.
Even if you open the BE database in shared mode, you
would expect it to be cached locally in the network
client cache if you are the only user. This is what
'opportunistic' locking does: opportunistical ly, when
you are the only user, it upgrades shared locks to
exclusive locks, enabling the system to cache the file
locally in the network client cache.
There were a series of bugs found in the caching and
opportunistic locking code of Windows 2000 (as evidenced
by multiple announcements that it had been fixed).
In fact, while you might expect local caching to reduce
network errors, it appears that historically, local
caching has always been worse, with logic, code, or network
errors causing cache corruption. Of course, most of these
errors are cache errors when you have multiple connections,
not cache errors in exclusive mode. The simplistic
explanation of the opportunistic locking problems was
that they happened when a share lock request was received.
In any case, turning off file caching (and opportunistic
locking) has always been a good idea when you get file
corruption.
The Jet database engine is a distributed database engine,
with the physical record locking semantics provided by
the file system. In a network file system the file system
is a distributed database, with the server represented by
a network client 'file redirector', which uses Server
Message Blocks to communicate with the file service on
the server.
Any network errors are effectively errors inside the database
engine, and in any case the SMB protocol does not appear
to be robust: if there was adequate error handling network
errors should not cause errors in the record handling.
However, I haven't seen inside: perhaps the Jet engine
just ignores errors which were not in the original DOS
file system and network redirector it was built to work
with.
(david)
"Wayne" <cq*******@volc anomail.comwrot e in message
news:11******** **************@ h48g2000cwc.goo glegroups.com.. .
David, I understand the meaning of your post now. Is this the only
reason that Access is more susceptible to network issues i.e. several
workstations are using the same backend? If, for instance, only one
workstation was using the server backend at a given time, is that
backend just as susceptible to a bad network connection as it would be
if several workstations were connected to it?
I'm interested in this because I have had one nightmarish situation
where a backend was being corrupted on a regular basis. To the best of
my knowledge usually only one person was accessing the backend at any
given time. The problem was traced to one of the workstations that had
a bad network connection.
In another case the server backend that was being corrupted only had
one workstation connected to it. The problem ended up being a faulty
network wall socket on that workstation.
Any more info on this subject is appreciated.
