"Chris O'C via AccessMonster.com" wrote:

> That happens when the first user opens the db exclusively.  Make sure they
> open it shared as the default db option and all users have read/write/modify
> permissions on the db file's folder.  The file must be on a hard drive, not a
> cd or dvd.
>
> Chris
>
>
> Thorson wrote:
> >I recently split my database and put the backend in a shared folder and
> >distributed the front end.  So far we have just tested it with 2 users.  When
> >one user has the front end open and the other user trys to open it an error
> >pops up saying the file is already in use.
> >
> >I am using Access 2007.  Is there something specific I have to do to allow
> >multiple users?
> >
>
> --
> Message posted via AccessMonster.com
> http://www.accessmonster.com/Uwe/Forums.aspx/access-security/200903/1
>
>

>I am not sure what yo mean by "Make sure they
>open it shared as the default db option"
>
>Is this a option I set in the database before distributing it?  Or do they
>have to open it from a shared folder?
>
>This is how we have it set up so far.  We have a shared folder on the
>network with the BE in it.  I have the FE on my desktop, I set this up to be
>linked to the BE and then distributed a copy of the FE (through E-mail) and
>had the users download a copy of the FE to their desktop.
>
>Should I actually place the FE in the shared folder and the open it from the
>shared folder every time?
>
>Thanks for your help.
>
>> That happens when the first user opens the db exclusively.  Make sure they
>> open it shared as the default db option and all users have read/write/modify
>[quoted text clipped - 10 lines]
>> >I am using Access 2007.  Is there something specific I have to do to allow
>> >multiple users?

"Chris O'C via AccessMonster.com" wrote:

> Open the back end db file.  Tools > Options > Advanced.
>
>     Default Open Mode
>     [X] Shared
>     [ ] Exclusive
>
> For distribution, you can continue emailing the front end to individual users
> who save it on their desktop or you can use Tony Toews's free tool to
> automatically update everybody's front end whenever you make changes and are
> ready to publish it.
>
> http://www.granite.ab.ca/access/autofe.htm
>
> Chris
>
>
> Thorson wrote:
> >I am not sure what yo mean by "Make sure they
> >open it shared as the default db option"
> >
> >Is this a option I set in the database before distributing it?  Or do they
> >have to open it from a shared folder?
> >
> >This is how we have it set up so far.  We have a shared folder on the
> >network with the BE in it.  I have the FE on my desktop, I set this up to be
> >linked to the BE and then distributed a copy of the FE (through E-mail) and
> >had the users download a copy of the FE to their desktop.
> >
> >Should I actually place the FE in the shared folder and the open it from the
> >shared folder every time?
> >
> >Thanks for your help.
> >
> >> That happens when the first user opens the db exclusively.  Make sure they
> >> open it shared as the default db option and all users have read/write/modify
> >[quoted text clipped - 10 lines]
> >> >I am using Access 2007.  Is there something specific I have to do to allow
> >> >multiple users?
>
> --
> Message posted via http://www.accessmonster.com
>
>

"Chris O'C via AccessMonster.com" wrote:

> The files should be in the users' trusted folders.  If you've got queries or
> properties which use unsafe expressions, don't allow the users to disable
> them when they adjust their macro security settings.
>
> Make sure the network is trusted by the users in Internet Explorer.
>
> Chris
>
>
> Thorson wrote:
>
> >Any other things I should check?
>
> --
> Message posted via AccessMonster.com
> http://www.accessmonster.com/Uwe/Forums.aspx/access-security/200903/1
>
>

"Chris O'C via AccessMonster.com" wrote:

> The users who don't have the network trusted can't open or connect to the db
> file on the network.  They'll get an error message the file isn't trusted and
> to download it to their hard drive.  That solution doesn't apply to Access db
> files.
>
> It's just one more thing to check for avoiding problems with multiuser dbs.
> You asked, so I gave it.
>
> Chris
>
>
> Thorson wrote:
> >The network is trusted by the users' internet explorer.... I'm not sure how
> >that would affect whether or not more than one person can open the FE though.
> > I probably just don't understand.
> >> The files should be in the users' trusted folders.  If you've got queries or
> >> properties which use unsafe expressions, don't allow the users to disable
> >[quoted text clipped - 5 lines]
> >>
> >> >Any other things I should check?
>
> --
> Message posted via AccessMonster.com
> http://www.accessmonster.com/Uwe/Forums.aspx/access-security/200903/1
>
>

"Chris O'C via AccessMonster.com" wrote:

> The file is being opened exclusively.  Are you sure both users are opening
> the front end as a file located on their own desktops (not a common location
> like the network share)?  If you are, list both users' permissions on the
> folder where the back end is.
>
> Chris
>
>
> Thorson wrote:
> >I am still having a problem with more than one user trying to open the
> >database.  When 1 user has the FE open and another tries to open the FE it
> >gives an error saying the file is already in use.  I did check and the
> >default open mode is set to shared.  I still need to fix this problem.
>
> --
> Message posted via http://www.accessmonster.com
>
>

>the other user has read only permissions.

>As I said in my first post, all users have read/write/modify
>permissions on the db file's folder.  Add write and modify permssions for the
>other user so he has all 3.
>
>Chris
>
>>the other user has read only permissions.

>Make that "all users *must* have read/write/modify permissions on the db
>file's folder".
>
>Chris
>
>>As I said in my first post, all users have read/write/modify
>>permissions on the db file's folder.  Add write and modify permssions for the
>[quoted text clipped - 3 lines]
>>
>>>the other user has read only permissions.

>Are you using a replica set or are both of you using the same FE file to
>access the database?
>
>I have not personally experienced this before, but I have some pretty
>extensive hands-on experience with using an Access BE and a repliated FE set.
>
>These kinds of things took me a while, please forgive me if you already know
>this stuff.  The shared folder must be set up so that all users have full
>"modify" access to the folder itself.  Then using the security settings (if
>you have set up user groups and such) you can control who can access/see/wrte
>whatever.  But like all MS programs, the FE is just a file, like a Word
>document, or more appropriately an internet web page.  Its just a window to
>look into the backend.  Most MS files have a first in, first user principle.
>The first person to open the file have full access and everyone else is read-
>only at best.
>
>If you can, create a replica set, a backend (BE), design master (DM), and a
>master replica (MR).  Have your testing user use the MR while you use the DM.
>I suspect this might solve the problem right up front.  I am not sure if its
>this posting, but the backend should not be replicated, you should split the
>database before replication.

>Pardon me, but you've got your information backwards.  Replication is for
>data, not db objects.  Not that Thorston needs it for his situation, but you
>can replicate the data, the back end, to synch it with data in other dbs.
>
>The front end should not be replicated.  You don't want to synch up changes
>in objects in the front end amongst many users unless you want db corruption.
>
>Chris
>
>>Are you using a replica set or are both of you using the same FE file to
>>access the database?
>[quoted text clipped - 17 lines]
>>this posting, but the backend should not be replicated, you should split the
>>database before replication.

>I could not disagree more.  When using a FE/BE setup, there is no need to
>replicate data because the data is sent from any FE to the BE directly.  In
>Access replication is for making "clones" of the master FE.  When structural
>changes are processed in the master FE the only way to get those changes into
>the replica is to synchronize - or to have every user replace their cloned
>(replicated) FE with a new one.
>
>I have spent many years working in replicated Access databases and I am not
>wrong.  I know that synchronization can be used to copy data from one FE to
>another FE, but replication is a way to clone the FE's.
>
>It may be that you are confusing SQL with Access, an all too common problem
>in Access boards.  As a SQL Server certified DBA I know that you are using
>the SQL definition of replication.  Why Microsoft used the same terms in
>different programs that do different things is a question for MS.
>
>I have not explored much into ADP files and perhaps in a distributed ADP
>synchronization is used to move data back and forth between FE's.  When using
>replicated MDB files, you go to Tools>Synchronization>Create Replica to make
>a clone of the FE.  Then to pick up changes to the structure in the front end
>a synchronization is run to the replica(s). 
>
>As for replicating data back and forth from one FE to another without a BE
>would be performed using the synchronization in Access, but users must be
>careful to process the changes to a table in only one place.  In my current
>db's I have local tables that contain static data that only occassionally
>needs additions or deletions.  In those cases, I change the data and run the
>synchronization to copy the data into the replicas.  Tools>Replication>Create
>Replica creates a FE.
>
>The Tools>Replication menu contains these options: Synchronize Now, Create
>Replica, Partial Replica Wizard, Recover Design Master, and resolve Conflicts.
>The Synchronize Now option will not even highlight until a replica is created.
>The Resolve Conflicts tool is used when data synchronized from a replica to
>the master does not match what was previously in the master (two users update
>the same table in two sources and try to synch one to the other).  In this
>case the user has to go through the errors to find which data source should
>be kept.  There is no "Replicate" or "Replication" menu option as the option,
>it is a sub-menu.
>
>So rather than being insulting, I will accept that you appear to be confusing
>multiple processes in Access with SQL terminology.
>
>
>Chris O'C wrote:
>>Pardon me, but you've got your information backwards.  Replication is for
>>data, not db objects.  Not that Thorston needs it for his situation, but you
>>can replicate the data, the back end, to synch it with data in other dbs.
>>
>>The front end should not be replicated.  You don't want to synch up changes
>>in objects in the front end amongst many users unless you want db corruption.
>>
>>Chris
>>
>>>Are you using a replica set or are both of you using the same FE file to
>>>access the database?
>>[quoted text clipped - 17 lines]
>>>this posting, but the backend should not be replicated, you should split the
>>>database before replication.

>I could not disagree more.  When using a FE/BE setup, there is no need to
>replicate data because the data is sent from any FE to the BE directly.  In
>Access replication is for making "clones" of the master FE.  When structural
>changes are processed in the master FE the only way to get those changes into
>the replica is to synchronize - or to have every user replace their cloned
>(replicated) FE with a new one.
>
>I have spent many years working in replicated Access databases and I am not
>wrong.  I know that synchronization can be used to copy data from one FE to
>another FE, but replication is a way to clone the FE's.
>
>It may be that you are confusing SQL with Access, an all too common problem
>in Access boards.  As a SQL Server certified DBA I know that you are using
>the SQL definition of replication.  Why Microsoft used the same terms in
>different programs that do different things is a question for MS.
>
>I have not explored much into ADP files and perhaps in a distributed ADP
>synchronization is used to move data back and forth between FE's.  When using
>replicated MDB files, you go to Tools>Synchronization>Create Replica to make
>a clone of the FE.  Then to pick up changes to the structure in the front end
>a synchronization is run to the replica(s). 
>
>As for replicating data back and forth from one FE to another without a BE
>would be performed using the synchronization in Access, but users must be
>careful to process the changes to a table in only one place.  In my current
>db's I have local tables that contain static data that only occassionally
>needs additions or deletions.  In those cases, I change the data and run the
>synchronization to copy the data into the replicas.  Tools>Replication>Create
>Replica creates a FE.
>
>The Tools>Replication menu contains these options: Synchronize Now, Create
>Replica, Partial Replica Wizard, Recover Design Master, and resolve Conflicts.
>The Synchronize Now option will not even highlight until a replica is created.
>The Resolve Conflicts tool is used when data synchronized from a replica to
>the master does not match what was previously in the master (two users update
>the same table in two sources and try to synch one to the other).  In this
>case the user has to go through the errors to find which data source should
>be kept.  There is no "Replicate" or "Replication" menu option as the option,
>it is a sub-menu.
>
>So rather than being insulting, I will accept that you appear to be confusing
>multiple processes in Access with SQL terminology.

>Darren, you don't understand Access replication.

> Please tell me that your DB's are perfect and ready for full-time,
> permanent use the day they implement.  Teach me how to get my end
> users never to ask for enhancements or new pieces.  Teach me how I
> get my DB's to be complete and perfect at implementation, because
> I don't know how to do that.  Then tell me why you choose to make
> me (or anyone) feel like my solution is the complete anti-Christ
> of networked Access databases that will bring about the end of the
> database world as we know it?  What's up with that?



> I looked at Tony Toewe's piece today and emailed him directly for
> more information.  I had only looked at products that required
> licensing in the past.  His tool is for networked pieces,
> potentially usable in my situation. No licensing fees is good.

>"Okay, since I am a complete moron who has no value and knows absolutely
>nothing"
>
>You're overreacting and exaggerating.  Chill out.
>
>"why in over five years (closer to six to count it out) have I not had a
>single incident of this?"
>
>You've been lucky, you have a stable network and apparently not too many
>complex objects or object synchs during that period.  But like a volcano,
>when they blow, they blow big time; you just never know when.
>
>"But you and others - who claim to be experts and MVPs - have chosen to tell
>me how useless I am"
>
>You're exaggerating.  Nobody, including me, told you you were useless.  You
>gave bad advice because you don't understand Jet replication and we said as
>much.
>
>"instead of taking the teaching opportunity to explain to me (and anyone else
>reading the post) what the point of having multiple backends in a multi-user
>network solution would be?"
>
>You ignored David Fenton's advice and were so busy telling us how confused
>Access users were, does it come as any surprise nobody took it as a teaching
>opportunity for you?  Sounded like you assumed you were the teacher - not the
>student - with that SQL Server cert and all.
>
>A typical case for replication is where some of the users will be off the
>network periodically or users work at a separate office building but they
>need to use the same data as everybody else and don't have a continuous
>network connection.  When they get back to the main office or connect to the
>main office from the other office over the Internet, they synch only the data
>through Jet replication.  Everybody has their own front end copy (with linked
>tables) so their Access sessions are separate from the other users'.  There's
>no copying Joyce's or Bill's special ad-hoc queries or forms to everybody
>else's front end "in case they need it".  Only the designated Access
>developer builds and distributes the db app to the users to maintain a
>carefully designed, normalized db which enforces data integrity.
>
>"How did you learn it?  Did you spend day after day reading books and online
>articles or did someone teach the basics to you?"
>
>Nobody had the skills or time to teach me.  I bought a big 10 lbs. Access
>book, read it at night and weekends, and took it to work with me every day.
>That taught me the basics, but not enough to do the jobs I needed to do.
>After work every day I read online articles and Access posts at Google Groups
>for at least 5 months, learning everything I could about developing Access
>dbs.  I read Allen Browne, Michael Kaplan, John Vinson, John Spencer, David
>Fenton, Lyle Fairfield, Tom Wickerath, Brendan Reynolds, 69Camaro, Doug
>Steele, Van T. Dinh, Joan Wild, Vanderghast and countless others - and
>learned about half what I know about Access from them.  I helped merge and
>upgrade thousands of dbs at 3 Fortune 100 companies after company mergers so
>I learned many tricks from the developers of those dbs.  Had to stabilize a
>lot of them first.  The worst were the replicated Jet dbs, they were often
>corrupted because the developers were office clerks, not software developers,
>who set up the dbs but didn't research how first.  I did a bunch of
>experimentation on my own time to see if I could come up with better ways to
>do things.
>
>That's how I learned Access.  Anybody else could too - except for maybe the
>thousands of dbs that needed merging and upgrading at 3 Fortune 100 companies.
>Not everybody gets that kind of opportunity.  But the most valuable stuff I
>learned online in Google Groups and through experimentation and anybody can
>do that on their own if they have a notion to.
>
>"Why would that user need a FE and a BE on their laptop in order to replicate
>over the data?"
>
>That remote user needs both the FE and BE on their laptop so when they're
>away from the office, they can work with data in the app.  They'll enter new
>data, maybe change some existing data when corrections need to be made at a
>client's office, maybe delete some unneeded records.  He/she gets back to the
>home office, and that valuable data needs to be shared with the other users.
>The data in the laptop's back end is synched with the data in the home office
>db and now everybody has the same set of updated data.  That's the plan at
>least.  You may have some conflicts to resolve when you synch.
>
>"And if you are not replicating the FE, how do you get and keep an up-to-date
>version of the FE on their machine?"
>
>Many developers use Tony Toews's autofe app to automate that.  It's free.
>Some developers rolled their own versions of Tony's app.  Some developers
>email their updated front ends to users because there's only a few and
>updates are rare.
>
>"Please tell me that your DB's are perfect and ready for full-time, permanent
>use the day they implement."
>
>You're upset and using hyperbole to stroke your ego, but your question
>doesn't address the topic of Jet replication, does it?  But I'll answer
>anyway.
>
>Don't design it that way, you'll fail.  Take a multi-phase approach.  Get a
>list of requirements and specifications you and the users agree to.  You must
>also agree on whether they can ask for changes to the requirements, because
>expanding scope during development is the most common reason for a software
>project's failure to meet deadlines and overspend the budget.  Give the users
>the most important features in the first phase.  Get feedback on what works
>the way they want, what doesn't.  Users will come up with new ideas once they
>see what's possible and change their minds on some of the original
>requirements too.  Give the users an upgrade to the first phase to fix the
>problems and add some additional important features.  Get feedback on what
>works, what doesn't.  Rinse and repeat until the requirements are met and the
>users are satisfied.  Try to do this within budget and deadlines.
>
>"Teach me how to get my end users never to ask for enhancements or new pieces.
>"
>
>You *WANT* the users asking for enhancements and new pieces.  You want them
>to ask this from *YOU*, not some other developer.  You want to keep working
>and paying the bills don't you?
>
>"Then tell me why you choose to make me (or anyone) feel like my solution is
>the complete anti-Christ of networked Access databases that will bring about
>the end of the database world as we know it?  What's up with that?"
>
>You're exaggerating again.  You gave very bad advice and you didn't listen to
>other posters who tried to correct you in the past 2 years.  You think we'd
>be silent?  No.  We just got your attention, we didn't throw you under the
>bus or nail you to a crucifix.  If you have tire treads on your clothes or
>nail holes in your wrists, you didn't get that from here.
>
>"Please, compel me to change it, apparently I am too stupid to do it on my
>own."
>
>I think you'll keep it just the way it is.  You're a certified SQL Server DBA
>and you think that gives you more than enough knowledge about how Jet and
>Access work.  It doesn't, but you won't believe me in a million years.  (Ok
>that's exaggeration, but you started it.)
>
>Chris

"Chris O'C via AccessMonster.com" wrote:

> Make that "all users *must* have read/write/modify permissions on the db
> file's folder".
>
> Chris
>
>
> Chris O'C wrote:
> >As I said in my first post, all users have read/write/modify
> >permissions on the db file's folder.  Add write and modify permssions for the
> >other user so he has all 3.
> >
> >Chris
> >
> >>the other user has read only permissions.
>
> --
> Message posted via AccessMonster.com
> http://www.accessmonster.com/Uwe/Forums.aspx/access-security/200903/1
>
>

>How do change my current .accdb database to .mdb?  What if I am using
>features only available in 2007 how will those be affected? 
>

>Yes, each user is opening his or her own copy, I am using an auto-updater
>program (http://www.granite.ab.ca/access/autofe.htm). 
>
>I had previously understood that I could set up user level security by
>setting permissions for the shared folder the back end is in, however this is
>preventing multiple users from opening the front end at the same time. 
>
>I am not using the Sharepoint Server.  The features I would like to keep are
>things such as when a animal health diagnosis is entered in a form it
>automatically pops up the options for the drug in another field; and if a
>drug is entered in that is not in the list a message box allows the users to
>select to edit the list.
>
>I am sure these features can be written using code in mdb format, but I have
>very little experience with Access and I currently have the database close to
>distribution, the ability to share the database is the only problem I am
>having.  I do not want to have to go back and spend days re-writing code and
>re-designing the database.

"Tom van Stiphout" wrote:

> On Tue, 24 Mar 2009 09:13:03 -0700, Thorson
> <Thor***@discussions.microsoft.com> wrote:
>
> What is your question?
>
> Your previous understanding is incorrect.
>
> -Tom.
> Microsoft Access MVP
>
>
> >Yes, each user is opening his or her own copy, I am using an auto-updater
> >program (http://www.granite.ab.ca/access/autofe.htm). 
> >
> >I had previously understood that I could set up user level security by
> >setting permissions for the shared folder the back end is in, however this is
> >preventing multiple users from opening the front end at the same time. 
> >
> >I am not using the Sharepoint Server.  The features I would like to keep are
> >things such as when a animal health diagnosis is entered in a form it
> >automatically pops up the options for the drug in another field; and if a
> >drug is entered in that is not in the list a message box allows the users to
> >select to edit the list.
> >
> >I am sure these features can be written using code in mdb format, but I have
> >very little experience with Access and I currently have the database close to
> >distribution, the ability to share the database is the only problem I am
> >having.  I do not want to have to go back and spend days re-writing code and
> >re-designing the database.
>

"Thorson" <Thor***@discussions.microsoft.com> wrote in message
news:BD82D80E-A94E-4FCA-B1F3-2B8CAAF17AAA@microsoft.com...
>I have a 2007 Access Database ready to distribute. The back end is in a
> shared folder which currently has restrictions on the permissions for
> different users.
>
> Before distributing it I wanted to do some checking to  make sure things
> were working.  So while I sent a copy of the front end to another user
> (who
> had read-only permissions).  I had that user download the front end to
> their
> desktop.  The database works fine for both my self (full permissions) and
> the
> user, however we cannot both open the Front end at the same time.  If the
> other user has it open and I try to open the front end it gives me
> read-only
> permissions, if I have the front end open and the user tries to open it
> Access states that the file is already in use.
>
> I thought the point of splitting the database was to allow multiple users
> to
> access the front end of the database at one time, however it is not
> working
> out that way. I need to know how to fix this problem.
> Thanks,
> --
> Thorson
>
>
> "Tom van Stiphout" wrote:
>
>> On Tue, 24 Mar 2009 09:13:03 -0700, Thorson
>> <Thor***@discussions.microsoft.com> wrote:
>>
>> What is your question?
>>
>> Your previous understanding is incorrect.
>>
>> -Tom.
>> Microsoft Access MVP
>>
>>
>> >Yes, each user is opening his or her own copy, I am using an
>> >auto-updater
>> >program (http://www.granite.ab.ca/access/autofe.htm).
>> >
>> >I had previously understood that I could set up user level security by
>> >setting permissions for the shared folder the back end is in, however
>> >this is
>> >preventing multiple users from opening the front end at the same time.
>> >
>> >I am not using the Sharepoint Server.  The features I would like to keep
>> >are
>> >things such as when a animal health diagnosis is entered in a form it
>> >automatically pops up the options for the drug in another field; and if
>> >a
>> >drug is entered in that is not in the list a message box allows the
>> >users to
>> >select to edit the list.
>> >
>> >I am sure these features can be written using code in mdb format, but I
>> >have
>> >very little experience with Access and I currently have the database
>> >close to
>> >distribution, the ability to share the database is the only problem I am
>> >having.  I do not want to have to go back and spend days re-writing code
>> >and
>> >re-designing the database.
>>