Best place to put FE db

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a FE/BE multiuser Access db. About 100 people have access to this database but very seldom will more that 10 people be on at once. My dilema is where to put the FE database. I know it is best to give each user a copy of it. The problem is most of the users are very inexperience users. When sending out a new update the likely hood of it actually making it to the proper place on their system is slim to none. Mapping a drive would be like brain surgery to some of these people. (I'm not intending to be mean. I sent out a copy to about 10 people to test the db. I included a manual with pictures and very easy instructions on how to map the drive and where to put the database. I still ended up doing mapping the drive and installing the database on each system. This is not feasible when we roll the finished product out to our Customer Service group). I then tried just leaving the FE on the server and sending out the needed workgroup and a shortcut without a drive mapped just using \\server\file. However the place where the our dear IT dept decide to allot us is five folders down and slows up the db completely. I have attempted to have this put closer to the root but our IT people say it won't help so they won't do it. I have done every thing possible on the Microsoft Access Performance FAQ that is posted on this site many times except putting the SQL in the Form Load and unload events. This causes problems with other code in the db. Any suggestions as to how to A) improve the performance of the db or B)automatically update the database on each users system

Thanks!!
 
I am wondering why you need to map a drive more that
once. Each user should have a mapped drive (same letter).
Then you simply place your back-end db in the folder of
the mapped drive and update the links to the tables in
the front-end. Then distribute the updated front-end.

I normally have an older copy of the back-end file that I
use while in devilopment of new features and I switch the
links from one back-end to the other so I do not modify
active data.

When distributing the front-end, all your users will have
to do is to save the file to the correct location or you
could distribute a zipped file using WinZip and make the
zipped file into an exe. Then all your users would have
to do is to run the WinZip exe file.

HTH

Byron
-----Original Message-----
I have a FE/BE multiuser Access db. About 100 people
Click to expand...
have access to this database but very seldom will more
that 10 people be on at once. My dilema is where to put
the FE database. I know it is best to give each user a
copy of it. The problem is most of the users are very
inexperience users. When sending out a new update the
likely hood of it actually making it to the proper place
on their system is slim to none. Mapping a drive would be
like brain surgery to some of these people. (I'm not
intending to be mean. I sent out a copy to about 10
people to test the db. I included a manual with pictures
and very easy instructions on how to map the drive and
where to put the database. I still ended up doing mapping
the drive and installing the database on each system.
This is not feasible when we roll the finished product
out to our Customer Service group). I then tried just
leaving the FE on the server and sending out the needed
workgroup and a shortcut without a drive mapped just
using \\server\file. However the place where the our dear
IT dept decide to allot us is five folders down and slows
up the db completely. I have attempted to have this put
closer to the root but our IT people say it won't help so
they won't do it. I have done every thing possible on the
Microsoft Access Performance FAQ that is posted on this
site many times except putting the SQL in the Form Load
and unload events. This causes problems with other code
in the db. Any suggestions as to how to A) improve the
performance of the db or B)automatically update the
database on each users system?
 
Thanks for replying. You solved my problem. Mapping the drive was not the biggest issue. If I have to do that personally for each user, then so be it because as you stated that is a one time issue. My biggest fear was not getting users to install the new updated version of the FE database. I didn't know Winzip could be made a exe file. Surely I can get people to click. Thanks!!
 
Tasha,

If you have WinZip installed on your computer, just right
click on any file, like your mdb file, and you should see
options for WinZip. Create a zip file by selecting one of
the "Add to" options. After the .zip file has been
created, place you cursor over the .zip file and right
click. This time one of the options will be "Create Self-
Extractor (.exe.).

As for you front-end/back-end situation: You should not
have mapping issues as long as you get everyone mapped at
the beginning.

Good Luck,

Byron
-----Original Message-----
Thanks for replying. You solved my problem. Mapping the
Click to expand...
drive was not the biggest issue. If I have to do that
personally for each user, then so be it because as you
stated that is a one time issue. My biggest fear was not
getting users to install the new updated version of the
FE database. I didn't know Winzip could be made a exe
file. Surely I can get people to click. Thanks!!
 
I then tried just leaving the FE on the server and sending out the needed workgroup and a shortcut without a drive mapped just using \\server\file
Click to expand...

If you use the Network Neighborhood in the linked table manager, the
links will be in this form and will not be dependent on any user's
drive mapping. The server might be one user's K drive and a different
user's W drive, but it wouldn't matter.
 
Tasha said:
My biggest fear was not getting users to install the new updated version of the FE database. I didn't know Winzip could be made a exe file. Surely I can get people to click.
Click to expand...

Don't count on users clicking and updating. Seriously. You send them
a shortcut in an email and many of them won't bother.

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.

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
 
Tasha said:
However the place where the our dear IT dept decide to allot us is five folders down and slows up the db completely. I have attempted to have this put closer to the root but our IT people say it won't help so they won't do it.
Click to expand...

Your IT people won't even let you do a timed experiment in their
presence? Sheesh.

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
 
The reply I got back was "I really don't think this will help as the time it takes for the server to check permissions even several folders deep is milliseconds." I tried to explain to them that milliseconds add up when the file has to check the permission for each folder 20 times. (I have 20 dropdown boxes on one form to help reduce mistakes.) Just accessing the folder that the database is in through my computer icon can take up to 90 seconds. I have no control over where the database is located though. (It is being stored on a server 350 miles away)
 
Tony

Thank you!!!!!!!!!!! You just made my life soooo much easier. Great utility. Easy to use. Works perfectly

Tasha
 
Tasha said:
The reply I got back was "I really don't think this will help as the time it takes for the server to check permissions even several folders deep is milliseconds." I tried to explain to them that milliseconds add up when the file has to check the permission for each folder 20 times. (I have 20 dropdown boxes on one form to help reduce mistakes.) Just accessing the folder that the database is in through my computer icon can take up to 90 seconds. I have no control over where the database is located though. (It is being stored on a server 350 miles away)
Click to expand...

Oh, hold on a sec here. The BE is on a server on a WAN? That's your
performance problem right there. And a huge potential for
corruptions.

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
 
Yes, the database is on a WAN. People from our site in Tennessee as well as three sites in Georgia have to access this database. Any suggestions as to the best way to accomplish this

----- Tony Toews wrote: ----

Tasha said:
The reply I got back was "I really don't think this will help as the time it takes for the server to check permissions even several folders deep is milliseconds." I tried to explain to them that milliseconds add up when the file has to check the permission for each folder 20 times. (I have 20 dropdown boxes on one form to help reduce mistakes.) Just accessing the folder that the database is in through my computer icon can take up to 90 seconds. I have no control over where the database is located though. (It is being stored on a server 350 miles away)
Click to expand...

Oh, hold on a sec here. The BE is on a server on a WAN? That's you
performance problem right there. And a huge potential fo
corruptions

Ton
-
Tony Toews, Microsoft Access MV
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.ht
 
Tasha said:
Oh, hold on a sec here. The BE is on a server on a WAN? That's your
performance problem right there. And a huge potential for
corruptions.

Yes, the database is on a WAN. People from our site in Tennessee as well as three sites in Georgia have to access this database. Any suggestions as to the best way to accomplish this?
Click to expand...

Probably Terminal Server. Requires paying MS $$$ though. Or use an
alternative method for the remote sites to access their data such as
ASP.NET. Which depending on the complexity of what they need to say
may not be too expensive.

Replication is an alternative but it needs attention and can be
troublesome.

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
 
Back
Top