Multi-user environments

[notaguru]

Our company has an Access 2000 database, which is stored as one .mdb file on
the server. 20 + users are in the database at any given moment during office
hours. Currently, when a user request a new report design or needs a new
module created, I design/test in a copy then import the changes into the
production database by copying it to my hard drive, import the changes and
recopy back to the server. (This is all done after-hours. We are up to 25
minutes down and 55 minutes up.)

How do I change the setup so that I can make changes (i.e. replace reports
with a new design, revise forms, add fields to tables, etc.) when others are
in the database? (Currently, if I try to change or replace an existing
report during working hours, we receive a message stating that the database
is not opened exclusively and design changes will not be saved.)

I would appreciate anyone pointing me in the right direction on how to solve
this….

 

[Duane Hookom]

First, I would split the database into a front-end of linked tables, forms,
reports, code, queries,... and a back-end of the tables only. Provide a copy
of the front-end for each user. Make changes to your master copy of the
front-end and distribute copies to each user as new versions are created.

Changes to tables should be very infrequent in a well-designed application.
You may need to keep all users out as you make changes to the back-end mdb
file.

Tony Toews has a utility for updating front-ends at
http://www.granite.ab.ca/access/downloadsindex.htm.

 

[Larry Daugherty]

Your application should be split into a FrontEnd and a BackEnd. There
should be a copy of the FE on each user's desktop. Once you've done
that you can play with your copy of both the front end and back end in
your own private sandbox until it's bullet proof and then put your new
master Front End on the server.

You need to make provision for updating the users' FEs when the master
copy on the server has changed. Look on Tony Toews's site for FE
Updater. He designed a solution to the problem which he makes freely
available for others to copy and modify.

Splitting the application is essential to maintainability. Automating
the updating process for the FrontEnds is the only way to assure that
your users are up to date without having to shut down the database for
the amount of time that it takes you to get around to every desktop to
make the update.


HTH

 

[notaguru]

Thank you for the info. I will give this a try.

First, I would split the database into a front-end of linked tables, forms,
reports, code, queries,... and a back-end of the tables only. Provide a copy
of the front-end for each user. Make changes to your master copy of the
front-end and distribute copies to each user as new versions are created.

Changes to tables should be very infrequent in a well-designed application.
You may need to keep all users out as you make changes to the back-end mdb
file.

Tony Toews has a utility for updating front-ends at
http://www.granite.ab.ca/access/downloadsindex.htm.

 

[notaguru]

Thank you very much. I now know what to do!

Your application should be split into a FrontEnd and a BackEnd. There
should be a copy of the FE on each user's desktop. Once you've done
that you can play with your copy of both the front end and back end in
your own private sandbox until it's bullet proof and then put your new
master Front End on the server.

You need to make provision for updating the users' FEs when the master
copy on the server has changed. Look on Tony Toews's site for FE
Updater. He designed a solution to the problem which he makes freely
available for others to copy and modify.

Splitting the application is essential to maintainability. Automating
the updating process for the FrontEnds is the only way to assure that
your users are up to date without having to shut down the database for
the amount of time that it takes you to get around to every desktop to
make the update.


HTH