dbTalk Databases Forums  

A2003 application in a small network: problem with opening

comp.databases.ms-access comp.databases.ms-access


Discuss A2003 application in a small network: problem with opening in the comp.databases.ms-access forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
imb
 
Posts: n/a

Default A2003 application in a small network: problem with opening - 01-17-2011 , 01:54 PM






Hello,

In a small local network 4 PC’s (WindowsXP) are connected to a shared
folder on one of them, PC1. In this folder there is an Access2003
application.

When PC2, PC3 or PC4 run the application as the first user, so
creating the .ldb, everything runs fine and all PC’s can run the
application at the same time, close it, run again etc.
However, when PC1 is the first user, and PC1 creates the .ldb, then
the other PC’s can not run the application anymore.
To keep things simple, it is in all cases the same application that is
used.

It looks like when a “guest” has created the .lbd file, “guests” may
modify it, including the “owner”, whereas when the “owner” has created
the .ldb file, only the “owner” may modify, and thus excluding
“guests”.

Has anyone a solution for this problem?

The workaround on this moment is not let PC1 use the application as
the first user.


Thank, Imb.

Reply With Quote
  #2  
Old   
Access Developer
 
Posts: n/a

Default Re: A2003 application in a small network: problem with opening - 01-17-2011 , 05:01 PM






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.

However, most experienced developers have a separate front-end for each
user, linked to tables in the backend; they also have a "development copy"
of the front-end (usually linked to a set of "development data") for
modification and testing. Once the changes are made and tested, they
distribute the new front end to the users. You may wish to consider this
approach, as it can prevent making unintended changes by accident.

You can include VBA code and data that will force the users to copy the new
front end from a shared file before proceeding or you can automatically
distribute the new copies using an Auto FE application such as you'll find
at MVP Tony Toew's site http://www.granite.ab.ca/accsmstr.htm. Tony's app
is not free, but it has been well-tested by uncounted users over the years.

Larry Linson
Microsoft Office Access MVP

"imb" <imb4u (AT) onsmail (DOT) nl> wrote

Hello,

In a small local network 4 PC’s (WindowsXP) are connected to a shared
folder on one of them, PC1. In this folder there is an Access2003
application.

When PC2, PC3 or PC4 run the application as the first user, so
creating the .ldb, everything runs fine and all PC’s can run the
application at the same time, close it, run again etc.
However, when PC1 is the first user, and PC1 creates the .ldb, then
the other PC’s can not run the application anymore.
To keep things simple, it is in all cases the same application that is
used.

It looks like when a “guest” has created the .lbd file, “guests” may
modify it, including the “owner”, whereas when the “owner” has created
the .ldb file, only the “owner” may modify, and thus excluding
“guests”.

Has anyone a solution for this problem?

The workaround on this moment is not let PC1 use the application as
the first user.


Thank, Imb.

Reply With Quote
  #3  
Old   
imb
 
Posts: n/a

Default Re: A2003 application in a small network: problem with opening - 01-18-2011 , 03:45 AM



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.

Reply With Quote
  #4  
Old   
Ron, paii
 
Posts: n/a

Default Re: A2003 application in a small network: problem with opening - 01-18-2011 , 07:29 AM



Open the application on PC1 and check the rights to the ldb file. The Guest
account need Read, Write access to this file.

"imb" wrote in message
news:d3ac3c41-f68a-4b11-a30d-0d0a5242a11e (AT) m7g2000vbn (DOT) googlegroups.com...

Hello,

In a small local network 4 PC’s (WindowsXP) are connected to a shared
folder on one of them, PC1. In this folder there is an Access2003
application.

When PC2, PC3 or PC4 run the application as the first user, so
creating the .ldb, everything runs fine and all PC’s can run the
application at the same time, close it, run again etc.
However, when PC1 is the first user, and PC1 creates the .ldb, then
the other PC’s can not run the application anymore.
To keep things simple, it is in all cases the same application that is
used.

It looks like when a “guest” has created the .lbd file, “guests” may
modify it, including the “owner”, whereas when the “owner” has created
the .ldb file, only the “owner” may modify, and thus excluding
“guests”.

Has anyone a solution for this problem?

The workaround on this moment is not let PC1 use the application as
the first user.


Thank, Imb.

Reply With Quote
  #5  
Old   
Access Developer
 
Posts: n/a

Default Re: A2003 application in a small network: problem with opening - 01-18-2011 , 02:05 PM



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.

Reply With Quote
  #6  
Old   
David-W-Fenton
 
Posts: n/a

Default Re: A2003 application in a small network: problem with opening - 01-18-2011 , 04:43 PM



"Access Developer" <accdevel (AT) gmail (DOT) com> wrote in
news:8pma4hFk0tU1 (AT) mid (DOT) individual.net:

Quote:
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.
There's nothing mysterious about why it doesn't work. It's because
the Access project is stored in a single BLOB field in a single
record in a system table, and when multiple users open the front
end, they are all contending for read/write locks on that single
record.

If you had a memo field in a table and made all your records open it
and write to that memo field simultaneously, you'd have corruption
of your memo field immediately -- no one would ever do that.

When you share a front end, you're doing the equivalent of that, but
with a much larger chunk of binary data, and one with a structure
that is much less knowable by the database engine.

It isn't complicated, as long as you understand the fundamentals of
what's going on.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

Reply With Quote
  #7  
Old   
David-W-Fenton
 
Posts: n/a

Default Re: A2003 application in a small network: problem with opening - 01-18-2011 , 04:44 PM



imb <imb4u (AT) onsmail (DOT) nl> wrote in
news:74299db3-068e-4499-b39c-752425f210eb (AT) w17g2000yqh (DOT) googlegroups.co
m:

Quote:
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.
Then you aren't interested in using Access correctly.

Read my response to Larry and see if you change your mind.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.