Re: Question about db deployment
- From: Preston <Preston@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 10 Jul 2008 17:06:03 -0700
Thank you very much for your explanation. I like to try and understand what
the software is actually doing so that I can setup and design things
properly. Thank you for taking the time to explain this to me. If you know of
anywhere where I can look at a logical layer diagram of access and a physical
layer as well I would greatly appreciate it.
"Marshall Barton" wrote:
The data locking file (.LDB) is in the same folder as the.
mdb file (one for the front end and one for each back end).
So the difference in sharing the front end or not is minimal
in this regard as long as you never modify an object
(query/form/report/...) on the fly. Modifying objects on
the fly is a really bad thing in either case, but can
completely mess over a shared FE.
OTOH, as I said before, Access does save housekeeping
information to the file so a shared FE may suffer odd
collisions, which then opens the door for unexplainable
corruptions and your entire shop will be down until you can
restore a good copy of the FE mdb to the server. This is
not something you can guard against, but you can easily do
simple things in the FE's design/code to make it much worse
(casual use of temp tables being an obvious example).
I have only heard of a couple of people that have managed to
reliably share a FE from a server to multple users.
However, I have heard of lots and lots of prople that are
sorry they ever entertained the thought of sharing a FE.
Locking for the data in back end tables is not an issue in
either scenario. Access performs all the appropriate checks
for multiple user's working on data in the same table and
will warn before (pessimistic) or after (optimistic) two
users edit the same record (actually a 2K block of records
for pesimistic locking).
Data is cached and flushed as needed on the machine that's
running the app, so that is only a performance improvement
technigue. The most important thing you can do to minimize
network traffic and improve performance is to use table
MVP [MS Access]
OK thank you for the reply. Can you explain a little more how access handles
the multiuser scenario in either case? i know that access just executes
queries and such over the network when each machine has its own front end. I
am assuming that access maintains some type of data cache on the local
machine that it updates to the backend when necessary. How does the software
handle multiple users when they all connect through the same front end file.
This is the situation where you say there is a higher chance for corruption
Since Access saves a fair amount of information in the
current database, it would be a potential disaster to share
the front end from a server.
Put a copy of the front end on each user's machine. I
recommend putting a copy on the server first and then
copying it from the server to each user's machine (I go so
far as putting code in the startup procedure to check if
it's running on the server and quitting if it is).
The difference is that one method can easily be corrupted
vs. the other requiring you to copy the file several times.
There are ways to automate the copy process using a program
like: http://www.granite.ab.ca/access/autofe.htm that can be
very helpful when you have relatively frequent modifications
Ok, thank you for the reply. I will run a copy of the front end on each
- Re: Question about db deployment
- From: Marshall Barton
- Re: Question about db deployment
- Prev by Date: Re: Question about db deployment
- Next by Date: RE: Carry forward balance of account
- Previous by thread: Re: Question about db deployment
- Next by thread: Re: Question about db deployment