Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsFormsForms ProgrammingQueriesModules / DAO / VBAReports / PrintingMacrosDatabase DesignSecurityConversionImporting / LinkingSQL Server / ADPMultiuser / NetworkingReplicationSetup / ConfigurationDeveloper ToolkitsActiveX ControlsNew UsersGeneral 1General 2
Access DirectoryToolsTutorialsUser Groups
Related Topics
SQL ServerOther DB ProductsMS OfficeMore Topics ...

MS Access Forum / Security / April 2007

Tip: Looking for answers? Try searching our database.

Lockout

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
John Grigsby - 26 Apr 2007 17:52 GMT
My office is using MS Access 2003 and we have a database stored on one
computer to which all other machines have been mapped.

At times, when one person is in the database, other users will be unable to
get in. I have found that this occurs when someone makes any changes to the
DB. At that point, Access "locks" it to prevent other people from getting in.
If the person dong the editing exits, the database is then "unlocked".

Has it always been this way? My co-worker insists that this did not happen
with earlier versions of Access.

Also, is there a work-around?
'69 Camaro - 26 Apr 2007 20:13 GMT
Hi, John.

> At times, when one person is in the database, other users will be unable
> to
> get in.

The proper way to design a multiuser database is to split the database into
a front end and back end.  The back end contains only the tables and
relationships, and this file remains on the networked server.  The front end
contains all of the other objects, i.e., queries, forms, reports, modules,
et cetera, with a link to each of the tables in the back end.  A copy of the
front end resides on each user's workstation, so that no one is sharing a
database file across the network.  Most locking issues go away with this
design.

> Has it always been this way?

No.

> My co-worker insists that this did not happen
> with earlier versions of Access.

It didn't happen with Access 97 and previous versions of Access, but those
versions allowed one user to modify and save an object while other users
were using the same object, thereby occasionally corrupting the object (and
therefore, the file) when saved.  Access 2000 and newer won't let you shoot
yourself in the foot.  Access 2000 and newer elevates the user's file access
to "exclusive" to save the object first.  If the user can't get exclusive
access to the database file prior to the save, the save fails, thereby
preventing corruption of the database file.

> Also, is there a work-around?

Not with Access 2000 and newer.  The user making design changes must have
exclusive access to the database file.  Either use a split database or go
back to the earlier versions of Access and the occasional database file
corruptions your current strategy invites.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.

> My office is using MS Access 2003 and we have a database stored on one
> computer to which all other machines have been mapped.
[quoted text clipped - 11 lines]
>
> Also, is there a work-around?
John Grigsby - 26 Apr 2007 22:38 GMT
Than you very much for your help and advice! I will look into splitting the
database soonest!

John
'69 Camaro - 27 Apr 2007 02:56 GMT
You're welcome.  Good luck!

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.

> Than you very much for your help and advice! I will look into splitting
> the
> database soonest!
>
> John
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.