Front End/Back End .mdb's over the network

[Guest]

I have an Access97 app with front and back end DB's, located in the same
directory. Users on other machines in the network can use the app
straightforwardly, by navigating to the front end .mdb. All machines had
W98. Recently the machine containing the app was converted to XP. The app
works fine (still Access 97) on that machine, but others (still on W98)
cannot use it. I was able to set up the front end/back end links is such a
way that all can use it, but it is very odd and artificial (basically the
links are fully described network paths, even for the user that doesn't need
the network).

Is there a better way to do this? I tried setting up the back end database
on a network server, but the response seems pretty slow for all.

 

[margaret bartley]

I have an Access97 app with front and back end DB's, located in the same
directory. Users on other machines in the network can use the app
straightforwardly, by navigating to the front end .mdb. All machines had
W98. Recently the machine containing the app was converted to XP. The app
works fine (still Access 97) on that machine, but others (still on W98)
cannot use it. I was able to set up the front end/back end links is such a
way that all can use it, but it is very odd and artificial (basically the
links are fully described network paths, even for the user that doesn't need
the network).

Is there a better way to do this? I tried setting up the back end database
on a network server, but the response seems pretty slow for all.

Are you saying that multiple people are opening up the same front end app
across the network?

If so, give every user their own front-end, and have them all pointing to
the
data on the server.

You are asking for trouble if you have several people opening the same
forms, reports, running the same queries, etc. Access can handle record-
locking well, but I've never had anything but grief when Access is trying
to handle multiple instances of documents.

Be sure to do a compact/repair on the front end before distributing them,
I wouldn't be surprised if it isn't already corrupted.

 

[Tony Toews]

I have an Access97 app with front and back end DB's, located in the same
directory. Users on other machines in the network can use the app
straightforwardly, by navigating to the front end .mdb. All machines had
W98. Recently the machine containing the app was converted to XP. The app
works fine (still Access 97) on that machine, but others (still on W98)
cannot use it. I was able to set up the front end/back end links is such a
way that all can use it, but it is very odd and artificial (basically the
links are fully described network paths, even for the user that doesn't need
the network).

Is there a better way to do this? I tried setting up the back end database
on a network server, but the response seems pretty slow for all.

There are several issues here.

1) The W98 uses will need to access the share on the Win XP box using
an account name and password which exists on that Win XP box user
list.

2) Sharing an FE can lead to corruptions of the FE. See below for
more info.

3) Putting your BE not on a server means that it likely isn't being
backed up on a regular basis.

4) Performance problems can also be dealt with but you will likely
find the same performance problems with a server as with your Win XP
box. See below for more info.

========================

2) However you really want to put the FE on each machine or place in a
user specific directory on the server. This will help avoid some
weird error messages when users are changing the same forms record
source, filters and such as well as corruptions.

I specifically created the Auto FE Updater utility so that I could
make changes to the FE MDE as often as I wanted and be quite confident
that the next time someone went to run the app that it would pull in
the latest version. For more info on the errors or the Auto FE
Updater utility see the free Auto FE Updater utility at
http://www.granite.ab.ca/access/autofe.htm at my website to keep the
FE on each PC up to date.

In a Terminal Server or Citrix environment the Auto FE Updater now
supports creating a directory named after the user on a server. Given
a choice put the FE on the Citrix server to reduce network traffic and
to avoid having to load objects over the network which can be somewhat
sluggish.

4) The three most common performance problems in Access 2000 or newer
are:
- LDB locking which a persistent recordset connection or an always
open bound form corrects (multiple users)
- sub datasheet Name property set to [Auto] should be [None]
- Track name AutoCorrect should be off

If the problem is for everyone when starting up the MDB then it likely
needs a decompile.

For more information on these, less likely causes, other tips and
links to MS KB articles visit my Access Performance FAQ page at
http://www.granite.ab.ca/access/performancefaq.htm

Tony


--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm