Because the Jet database engine executes in the user's machine, and because
it creates files/storage "behind the scenes", the risk of corruption is
significantly increased when multiple users log in to the same copy of the
front-end. It is not a matter of just "making changes". You may go for a
long time without having a problem, make some minor change, and have
problems on a regular basis thereafter.
Multiple users logged into / using the same monolithic database or the same
front end is not a _recommended practice_. If you are seeking a further
explanation of this, then you probably need to see if you can get it from
Microsoft -- and I am not sure they are interested in releasing details of
Access' internal operation. As for me, I have seen enough problems of this
kind that I am convinced that it can, and does happen, and I am unwilling to
expose myself / my users if there is even a relatively low probability.
Try giving the owner a separate, different userid to use with the production
copy, which does not have permissions to modify, and use that -- that's
likely to be the very simplest workaround.
Or, as I said, without changing the owner's USERID have the owner open
Access first, log in and specify "not for exclusive use", then load the
production application, and see if you still have the problem. If it works
OK for you, then that shows that the reason was that, by default, the
database owner was opening the DB "for exclusive use".
If that turns out not to be the problem, then perhaps someone who's had more
experience debugging similar occurrences than I have can be of more help.
Fortunately, on most of my client work (and, of course, all of my personal
databases), I have had the good fortune of being able to follow "good",
"recommended", or "best" practices and simply avoided a lot of problems of
similar nature.
Regards,
Larry Linson, Microsoft Office Access MVP
"imb" <imb4u (AT) onsmail (DOT) nl> wrote
Hi Larry,
Thanks you for your answer. I always like your quiet style of
responding.
But alas, your answer did not help me much.
Quote:
In recent versions, to modify the application, you must open it for
exclusive use. IIRC, that setting is saved by username. If you first
open
access not for exclusive use, then enter as the owner's userid, you should
not have this problem. |
I did not understand fully what you mean with the above paragraph.
There is a strict separation between a development environment, where
the application can be modified, and a production environment, where
the application can not (or may not) be modified. Each application has
a splitted front end and back end.
In fact, for the users of the productions application it is never
necessary to modify the front end. In the applications is already
build in all the flexibility they need. Four different-type
generalized forms and a couple of metadata tables can make anything
the users need. No Querydefs are used, because the necessary SQL-
string is generated on the spot when needed.
So, no modification of the FE occurs, no bloating of the FE, no
chances (or at least far less) of corruption, no unintended changes by
accident. But also, at least from this aspect, no need to give each
user have his own single user FE, in order to modify.
Now back to my question. The application works well as a multi-user
FE, where PC1, PC2, PC3 and PC4 can use the application simultanously
and without problems. At least, when PC2, PC3 or PC4 create the .ldb
file. As soon as PC1 – where the application is stored – is the first
user and creates the .ldb file, then PC2, PC3 and PC4 can not use the
application anymore.
How can this happen? That is the problem that I want to understand. In
my opiniuon it is not a typical Access problem, but lies in the
interaction between Access an Operating system.
I agree that when you give each user his own single user FE than you
do not feel this problem. But I am not satisfied with that solution.
It is as when a patient comes to a doctor and says: “Doctor, when I
press here, it hurts”, and the doctor answers: “Well, don’t press.”
A separate FE per user does not solve the problem immediately. Each FE
has reference to a library-database to drive the metadata, and this
library-database also creates a .ldb, with the same restrictions. So
each separate user (PC) should then have its own FE ŕnd library-
database. Can Tony’s Auto FE loader handle this?
But again, this direction in not the intention of my original
question.
Thanks, Imb.