MDE - solution to multiple users ?

[SWmiller]

I am very rusty on my Access knowledge and I created a database that I want multiple users (about 10-12) to have access to simultaneously.

I stored it on my server and mapped the users to the .mdb with no problem.

One user is able to open it and update it, but when another user attempts to open it at the same time, it gives one of the following errors:
- the database is already in use
- you are prevented from opening or locking the file (can't remember it exactly)
* I have not specified any restrictions on opening or record locking

However, out of desperation, I tried saving the database as an MDE file and so far I have had success with 2 users accessing the database. So my questions is, was this the appropriate way to run a multiuser database? If not, any advice into the right direction will be appreciated.

 

[grnzbra]

You could use unbound forms to limit the conflicts.

 

[petermeachem]

Are they all accessing the same file on the server? Better solution is to split it with the data files on the server linked to the forms etc on the users pc's. Peter Meachem
peter@accuflight.com

Support Joanna's Bikeathon

http://www.accuflight.com/blue_peter_bikeathon_2002.htm

 

[SWmiller]

Yes, they would be accessing the same file. Would that not be efficient?

Also, I am a little unclear when you say "split it" and "linked" to the user's PC's.

Like I said, I am extremely rusty on Access. It's been over a year since I used it. If it makes it any easier on you, I am using the Contact Management DB template in Access 2000. That may give you a better picture of what the users are accessing and updating.

Thanks for your advice.

 

[petermeachem]

So do I. Good isn't it.
Go to Tools / Database Utilities / DatabaseSplitter

(take a copy first)

You want to end up with calls , contact types and contacts on the server as the back end. Then on the workstations, use the linked table manager to attach those tables. Actually, I think the splitter does that for you, but leaves the front and back ends in the same place. You need back end on server, front end on workstation and then relink the workstation so it is pointing to the server.

Please take a copy first!!!
Peter Meachem
peter@accuflight.com

Support Joanna's Bikeathon

http://www.accuflight.com/blue_peter_bikeathon_2002.htm

 

[SWmiller]

Yes, it's very nice.

I'll be working on it later this morning, and I'll post if I have any questions. Thanks again for your help.

 

[SWmiller]

Peter,

now that I have my back-end file on the server and the front-end on my PC, is it normal that the front-end file still contains the tables in it? I thought they should just be on the back-end.

thank you

 

[Junior1544]

the tables should just be in the back end... there should be links to the tables in the front end...

this makes it look like tables are in the front end, but there is a black arrow next to the table... that means it's linked...

--Junior JHauge@jmjpc.net
Life is change. To deny change is to deny life.

 

[SWmiller]

Okay, I see.

I am just concerned that my users will open the linked tables out of curiousity and start deleting records they are not supposed to. Can this be resolved with Permission settings?

 

[petermeachem]

No more likely than at the moment and you can hide the database window. Oh and don't forget the mde bit. Peter Meachem
peter@accuflight.com

Support Joanna's Bikeathon

http://www.accuflight.com/blue_peter_bikeathon_2002.htm

 

[SWmiller]

Do you mean I still need to save the front-end as an MDE file?

 

[petermeachem]

You don't need to, but it is supposed to be a bit quicker and will stop people fiddling about with it. Peter Meachem
peter@accuflight.com

Support Joanna's Bikeathon

http://www.accuflight.com/blue_peter_bikeathon_2002.htm

 

[Junior1544]

one more thing... this i've heard of, but not seen...

if two users try to use the same uncompiled form(in a mdb) at the same time, they will both try to compile it, and that will make one or both of them fail... just another thing to think about...

--Junior JHauge@jmjpc.net
Life is change. To deny change is to deny life.