Concurrent Access Security Problem

[Tim Traylor]

Hi,

I'm having a problem with multiple concurrent users accessing databases.
Here's one example:

Access 2000.
Secured, split database.
Back end and MDW file are on a network share.
Front end and shortcut w/MDW pointer are on local PC's.
The first two users to access the database get in fine.
Any additional user that tries to access the database receives the message:
“Microsoft Access couldn't find the file 'NetworkDrive:MDWFileName.MDW'.
This file is required for start-up.".

Here's the background info:
Concurrent access was working when the users we're running Windows 98 and
Access 2000.
The problem began after IT rolled out a new desktop image with Windows 2000
and Office 2000.
The server is running a current version of Novell, and users have read,
write, create, and delete access to the network share.
All Windows and Office 2K service packs are current.

Here's what we've tested:
The problem occurs on any secured database, existing or new.
Any combination of 2 users can concurrently access the database; any 3rd
user attempting access gets the error.
All shortcut pointers for opening the db have the correct information.
All db files have been compacted and repaired.
The MDW file name displayed in the error message is the correct file, but
the file (which it says can't be found) is visible in Explorer.
To test rights, users were given admin to their desktops and full access to
the network share.
The default Access open option is 'shared'.
When I copied the MDW file to their local PC's and changed their shortcuts
the problem does not occur, so it is definitely a problem with the MDW and
not an erroneous error message.

The only thing that I see that is unusual or wrong is that when I view the
ldb file for the mdw I only see an entry for the second user who is
currently logged on. The first user, who is still connected, is not listed
in the file.

In ten or so years of working with Access I've never seen this happen and
I'm truly stumped. Any thoughts on how to proceed would be greatly
appreciated!!

Thanks,
Tim

 

[TC]

That would have to be the best problem description that I have seen in
this group for quite some time!

A key aspect (as you well know) is that it is apparently not dependent
on which PCs you use for the test. /Any/ two pc's open fine, then the
/next/ pc (whichever it is) does not. So it seems that the problem is
not pc dependent.

Since nothing else springs to mind, here's the first thing I would
try. Emulate the process using a non-Access file. That is, give three
of the pc's a shortut which runs Notepad (say) to open a shared text
file on the server. Put the shared text file in the same folder as the
workgroup file & give it the same permissioins. Maybe even use a copy
of Notepad which you put in the same older is msaccess.exe - just to
make it evn closer to the problem configurtion.

If the problem appears in this case also, it immediately tells you that
it is a file sharing problem of some kind, and nohing to do with Access
as such.

It's a bit of a stab in the dark, but worh trying IMHO.

HTH,
TC

 

[TC]

PS. Another idea which I vaguely remember suggesting to someone else
some time ago: use a file monitor to see /exactly/ how the pc is
trying to open the shared workgroup file; ie. check the exact opening
permissions requested, and the exact error number or message that is
returned. Maybe (for example) a file monitor would show that the actual
error is "file not able to be opened for sharing", which Access then
wrongly translates to "file not found".

Sysinternals (www.sysinternals.com) should have such a tool. Their
tools are free, small & very easy & simple to use.

HTH,
TC

 

[Tim Traylor]

TC,

I think that sysinternals Filemon utility might be just what we need to
figure out what's happening.

Thanks for the suggestions!

Tim

 

[TC]

Good luck! Get back & tell us what happens.

TC

 

[Guest]

Years ago on Novell. all my data files were also marked as Shared.
(I didn't know what the s and t flags meant, so I set them to
be true. If there still is a t flag, it should not be set).

/Check/ that the release of Office 2000 they are rolling out is
actually SR3. (don't take their word for it).

I get different results on the Workgroup file when I open the
Application file in Exclusive mode, and something different
when I enable Record Level locking.

I guess you are rolling out different network client software
as well. Check that has no known problems.

(david)