Split Database Multi User

I

irvine.jim

I have a split database with 5 users sharing the same back end. The
problem we are having is when one of the users is sitting on a
customer list and another user goes intoo the same form and selects a
different customer, the first users customer changes to the customer
that the second user selected. Any help would be really appreciated,

Thanks
 
A

Arvin Meyer [MVP]

The only way that could happen is if they were also sharing the same
front-end and you had code forcing the change everywhere. Make sure that a
copy of the front-end is on each user's workstation, or if using a Terminal
Server, that there is a separate folder for each user with a copy of the
front-end in it.
 
I

irvine.jim

The only way that could happen is if they were also sharing the same
front-end and you had code forcing the change everywhere. Make sure that a
copy of the front-end is on each user's workstation, or if using a Terminal
Server, that there is a separate folder for each user with a copy of the
front-end in it.
--
Arvin Meyer, MCP, MVPhttp://www.datastrat.comhttp://www.mvps.org/accesshttp://www.accessmvp.com







- Show quoted text -

All users take a copy of the front end and place it on their desktops,
they then use the linked table manager and connect to the back end in
a shred folder on another pc.
 
G

George Nicholson

Then whatever is controlling what appears in the form filter is in the
backend and it shouldn't be.

For example, what happens when a new customer is selected?
- If the selected value is used by a query in the backend, all users will
see the change. Bad
- If the selected value triggers some flag being set in a backend table, any
queries based on that flag will see the change regardless of where the query
is. Also bad.

If the selected value is used by a query in the frontend, each user sees the
result of their selection and only their selection. Good.

Backend: data only
Frontend: Forms, reports, queries, code, (and possibly a small amount of
user data (most recently used) or very static data (a list of state codes))

--
HTH,
George



The only way that could happen is if they were also sharing the same
front-end and you had code forcing the change everywhere. Make sure that a
copy of the front-end is on each user's workstation, or if using a
Terminal
Server, that there is a separate folder for each user with a copy of the
front-end in it.
--
Arvin Meyer, MCP,
MVPhttp://www.datastrat.comhttp://www.mvps.org/accesshttp://www.accessmvp.com







- Show quoted text -

All users take a copy of the front end and place it on their desktops,
they then use the linked table manager and connect to the back end in
a shred folder on another pc.
 
J

Jeff Boyce

Are you absolutely, positively certain that they have a copy of the
front-end file, and not just a copy of a link to a (single) front-end that
lives on your network?

Regards

Jeff Boyce
Microsoft Office/Access MVP

The only way that could happen is if they were also sharing the same
front-end and you had code forcing the change everywhere. Make sure that a
copy of the front-end is on each user's workstation, or if using a
Terminal
Server, that there is a separate folder for each user with a copy of the
front-end in it.
--
Arvin Meyer, MCP,
MVPhttp://www.datastrat.comhttp://www.mvps.org/accesshttp://www.accessmvp.com







- Show quoted text -

All users take a copy of the front end and place it on their desktops,
they then use the linked table manager and connect to the back end in
a shred folder on another pc.
 
T

Tom Wickerath

That's exactly my thought. Those funny users....when you tell them to copy
the file to their local hard drive, what do they sometimes do anyways? You
guessed it, they simply double-click the file. I know first hand from seeing
what students would do in an Access course that I used to teach at Bellevue
Community College. All of a sudden, I'd notice a locking database file
(*.ldb) for the front-end .mdb file that I had instructed them to copy to
their hard drive first, before opening it.

Jim:
There is no reason that each user should have to use the linked table
manager to re-link their copies. You can use a UNC (Uniform Naming
Convention) path when re-linking your tables, so that they are not dependent
on a particular drive letter being mapped correctly. A UNC path looks similar
to this: \\server\share\FolderName\Database.mdb

I also recommend using Access MVP Tony Toews' AutoFE Updater utility. This
utility takes all of the pain out of providing updates to each user:

http://www.granite.ab.ca/access/autofe.htm
and http://www.granite.ab.ca/access/autofe/gettingstarted.htm

Also, see this article for additional tips:

Implementing a Successful Multiuser Access/JET Application
http://www.accessmvp.com/TWickerath/articles/multiuser.htm


Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________
 
I

irvine.jim

That's exactly my thought. Those funny users....when you tell them to copy
the file to their local hard drive, what do they sometimes do anyways? You
guessed it, they simply double-click the file. I know first hand from seeing
what students would do in an Access course that I used to teach at Bellevue
Community College. All of a sudden, I'd notice a locking database file
(*.ldb) for the front-end .mdb file that I had instructed them to copy to
their hard drive first, before opening it.

Jim:
There is no reason that each user should have to use the linked table
manager to re-link their copies. You can use a UNC (Uniform Naming
Convention) path when re-linking your tables, so that they are not dependent
on a particular drive letter being mapped correctly. A UNC path looks similar
to this: \\server\share\FolderName\Database.mdb

I also recommend using Access MVP Tony Toews' AutoFE Updater utility. This
utility takes all of the pain out of providing updates to each user:

         http://www.granite.ab.ca/access/autofe.htm
and    http://www.granite.ab.ca/access/autofe/gettingstarted.htm

Also, see this article for additional tips:

         Implementing a Successful Multiuser Access/JET Application
         http://www.accessmvp.com/TWickerath/articles/multiuser.htm

Tom Wickerath
Microsoft Access MVPhttp://www.accessmvp.com/TWickerath/http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________




- Show quoted text -

Thanks for the input guys.

George I will look at some of the forms and see what they are calling
from the back end.

I am absolutley sure each user has their own copy of the fron end
because I SMS's into each machine and copied the front end myself to
each user.

I'll also have a look at the Auto update info, Thanks Tim
 
Top