Access 97 /Runtime Causing Locked by User Preventing Other Users From Logging In

Access 97 /Runtime Causing Locked by User Preventing Other Users From Logging In

Post by ano1optimi » Wed, 17 Sep 2003 07:58:15


We've got users sharing a database where the front end apps reside on
the local PC while the backend app is on the network. We have
repeated problems where certain users lock the database causing other
users to get the Run-time error , currently locked
by user 'admin' on machine 'xyz' when trying to log into the database.
The users have a "/runtime" command on the property of their desktop.

Can you clarify how the runtime works? My understanding is that the
full-blown Access can not/ should not be installed on a PC where the
runtime version will be used. This is not the case. I could not
locate any full-blown access version on the local PC. Is there an
initialization file installed with the runtime that determines how the
database is opened or what record locks are used by default? I did not
deploy this so I'm not familiar with the installation setup used. Is
there a way to verify what runtime version is installed and what the
property settings for opening the database are set at?

The forms level security is set to Record Locks = No Locks on all
forms.

Thanks, in advance, for your suggestions.
 
 
 

Access 97 /Runtime Causing Locked by User Preventing Other Users From Logging In

Post by ano1optimi » Fri, 19 Sep 2003 12:26:28

I will document my findings in the event that it might help someone
later. The Access 97 db was using a system.mdw file, which no one was
aware of. It contained the standard 2 users and groups. The admin
user and user group had open/exclusive rights to the db. Once we
removed those rights, the administrative locking message disappeared.
I wasn't too familiar with Access 97' use of system.mdw although I
have worked with Access 2000 system.mdw. I was surprised to learn
that I didn't see any reference to the system.mdw in the shortcut
property (ie. /wrkgroup with reference to its location). I had to use
Tools (if I recall correctly) to determine what system.mdw file was
being used. Or, maybe it was the workgroup administrator application
that pointed me to the correct location. Sorry but I searched so many
options looking for the right solution. Once I found the reference to
the system.mdw and the open/exclusive permissions on the database
object and removed them, it worked just as expected.