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 / Setup / Configuration / April 2004

Tip: Looking for answers? Try searching our database.

Splitting a Microsoft DB

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Rick - 13 Apr 2004 17:18 GMT
We presently have a DB residing on our LAN server and are
considering splitting it to permit modifications to the
front-end without booting everyone out of program.  I'm
not sure that I totally understand the concept of
splitting the DB and have a few questions:

1.  The present thought is to split the DB leaving the
front-end in the directory on the server where it
presently resides and to place the backend (tables) in
another directory on the same server.  I know this will
not reduce network traffic.  However; it will a least
keep the front-end on the server and any modifications
done will be available realtime to several users. Is this
a practical option or does one have to place a front-end
on 35 PC's and find a method of updating them all with
the latest changes made to the front-end from time to
time?

2.  We have full security on the existing DB and wonder
if there are any negative consequences of splitting the
DB at this time?

TIA
Joan Wild - 13 Apr 2004 18:04 GMT
> 1.  The present thought is to split the DB leaving the
> front-end in the directory on the server where it
[quoted text clipped - 3 lines]
> keep the front-end on the server and any modifications
> done will be available realtime to several users.

This is not so, if you are using Access 2000 or higher.  You must have
exclusive access to the mdb to make design changes.
> Is this
> a practical option or does one have to place a front-end
> on 35 PC's and find a method of updating them all with
> the latest changes made to the front-end from time to
> time?
\
That is the better solution.  With that many users, you run an increased
risk of corruption with them all using the same frontend.  Give each user a
copy and update when you've finished modifying the frontend and tested it.
Tony Toews has a utility you can use to update the frontends automatically.
See
http://www.granite.ab.ca/access/autofe.htm

> 2.  We have full security on the existing DB and wonder
> if there are any negative consequences of splitting the
> DB at this time?

Very glad you asked before proceeding.  Don't use the splitter wizard -
you'll end up with a secure frontend, but an unsecured backend.  Instead
split it manually to ensure both remain secure - it's easy to do.

Make a copy of your mdb - this will be the backend.  Open the backend and
delete all objects except the tables/relationships.  Open the frontend and
delete the tables/relationships.  Then go to File, Get External Data, Link -
find the backend and link to its tables.  If you use Network Neighborhood to
find the backend on the server, the links will use UNC pathnames.  When you
copy the frontend to each user, you then won't need to worry if users have
the same drive mappings as you.

Signature

Joan Wild
Microsoft Access MVP

 
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.