locked
Front end, multiple users RRS feed

  • Question

  • Hello all-

    If I have a split database, and put the front end on the network, can my users place a shortcut to that front end, and multiple users access it simultaneously?

    I mean...I know they can all place shortcuts to the FE on their desktops.  What I'm wondering is whether multiple people can access their own shortcuts (all pointing to the same FE application), and use it simultaneously). 

    Thanks!

    Casey

    Tuesday, June 9, 2015 4:30 PM

Answers

  • If I have a split database, and put the front end on the network, can my users place a shortcut to that front end, and multiple users access it simultaneously?

    I mean...I know they can all place shortcuts to the FE on their desktops.  What I'm wondering is whether multiple people can access their own shortcuts (all pointing to the same FE application), and use it simultaneously). 

    You can do that, but it's not a recommended configuration.  Multiple users opening the same front-end on a network share is subject to these negative effects:

    1. Because the design of all objects has to be read across the network, it slows down the operation of the application.

    2. Because Access wants to store the design of objects when you do things like set filters or sorts, the need to do it across the network slows things down, plus the various users will be stepping on each other's changes.

    3. Because design changes are saved across the network, there's a greater chance of a network glitch causing corruption in the front-end.

    4. If different users are using different versions of Access and Office, you run into the situation where library references can be upgraded to the highest version of any user, and then can't be automatically downgraded for lower-version users, which can cause the front-end to fail for those users.

    5. If your front-end undertakes any design changes at run time, users will not be able to get exclusive access to the front-end to do that.

    6. If your application uses any temporary or work tables in the front-end, users will be overwriting each other's data in those tables.

    Not all of these issues will affect all installations, and some can be worked around, but you should be aware of the issues before deciding to share a single front-end database over the network.


    Dirk Goldgar, MS Access MVP
    Access tips: www.datagnostics.com/tips.html

    • Proposed as answer by RunningManHD Tuesday, June 9, 2015 10:24 PM
    • Marked as answer by Casey_M Wednesday, June 10, 2015 11:46 AM
    Tuesday, June 9, 2015 10:06 PM

All replies

  • I do that, but I have the backend on the network as well.  I also use the UNC path for the links to the backend in my frontend.  This insures all users with access to the network will see the data regardless of what their network drive letter is.  http://compnetworking.about.com/od/windowsnetworking/g/unc-name.htm


    If this post answered or helped you find the answer to your question, please mark it as such for other Forum users knowledge.

    Tuesday, June 9, 2015 5:08 PM
  • If I have a split database, and put the front end on the network, can my users place a shortcut to that front end, and multiple users access it simultaneously?

    I mean...I know they can all place shortcuts to the FE on their desktops.  What I'm wondering is whether multiple people can access their own shortcuts (all pointing to the same FE application), and use it simultaneously). 

    You can do that, but it's not a recommended configuration.  Multiple users opening the same front-end on a network share is subject to these negative effects:

    1. Because the design of all objects has to be read across the network, it slows down the operation of the application.

    2. Because Access wants to store the design of objects when you do things like set filters or sorts, the need to do it across the network slows things down, plus the various users will be stepping on each other's changes.

    3. Because design changes are saved across the network, there's a greater chance of a network glitch causing corruption in the front-end.

    4. If different users are using different versions of Access and Office, you run into the situation where library references can be upgraded to the highest version of any user, and then can't be automatically downgraded for lower-version users, which can cause the front-end to fail for those users.

    5. If your front-end undertakes any design changes at run time, users will not be able to get exclusive access to the front-end to do that.

    6. If your application uses any temporary or work tables in the front-end, users will be overwriting each other's data in those tables.

    Not all of these issues will affect all installations, and some can be worked around, but you should be aware of the issues before deciding to share a single front-end database over the network.


    Dirk Goldgar, MS Access MVP
    Access tips: www.datagnostics.com/tips.html

    • Proposed as answer by RunningManHD Tuesday, June 9, 2015 10:24 PM
    • Marked as answer by Casey_M Wednesday, June 10, 2015 11:46 AM
    Tuesday, June 9, 2015 10:06 PM
  • Based on the issues Dirk reported above, I've been more comfortable providing users a shortcut which copies the 'master' front end to their own local disk and then runs that local copy. The only difference to the user is a second or two while the front end gets copied.

    Paul

    Thursday, June 11, 2015 4:52 PM
  • Based on the issues Dirk reported above, I've been more comfortable providing users a shortcut which copies the 'master' front end to their own local disk and then runs that local copy. The only difference to the user is a second or two while the front end gets copied.

    Paul


    If what you are saying is that you are now copying the front end to the user's machine every time they need to use it, that sounds like a recipe for problems.  I would only update the user's copy when updates have been done and at a convenient time when they aren't utilizing the system.  That's just my advice...
    Thursday, June 11, 2015 7:14 PM
  • What problems do you foresee? I've used logic like that for years without any problems. The only concern is to ensure that no user can ever run the master front end directly.

    Paul

    Thursday, June 11, 2015 7:32 PM
  • The one problem that comes immediately to mind is that, however unlikely, a fault could occur during the copy process, leaving the user without a working copy until support can resolve the issue. If their business is dependent on the database, that would be a major problem.  The chances for such an issue are far greater than rolling out updates only when necessary.  That and any lag time the user might experience in downloading the copy from the server.
    Thursday, June 11, 2015 8:03 PM
  • No RunningManHD, he is not saying copy it every time a user needs it. Copy it to their machine once. It remains there on each users PC.
    Thursday, June 11, 2015 8:03 PM
  • Actually I do copy it every time. Since the master front end is hosted on the same server share as the backend, if they can't copy the front end it means they wouldn't be able to work in the database even if they used their local front end copy. For laptops that might be used without access to the server, I gave them an option to make a readonly copy of the backend and then run that with the last front end they had copied.

    I don't remember ever having problems with this. It simplifies rolling out updates, eliminates front end bloat, and automatically recovers from any possible front end corruption.


    Paul

    Thursday, June 11, 2015 8:15 PM
  • Just another approach used here; Each user has a shortcut on their desktop to their designated copy of the FE on the server. The FE's and BE are in the same folder. This has been working without issue for almost 5 years now.

    This allows for quick easy updates. I delete the old files and make the new files with the same names as before so the shortcuts always work. I don't really see a downside to this. The db's always open fast and function well. Never crashes.

    FE's are 21mgb

    BE is 750mgb

    22 users


    Just takes a click to give thanks for a helpful post or answer.
    Please vote “Helpful” or Mark as “Answer” as appropriate.
    Chris Ward
    Microsoft Community Contributor 2012

    Thursday, June 11, 2015 8:46 PM
  • Just another approach used here; Each user has a shortcut on their desktop to their designated copy of the FE on the server. The FE's and BE are in the same folder. This has been working without issue for almost 5 years now.

    That solves some of the problems, though it will slow down the application slightly as front-end object definitions have to be read from the server, and is likely to be somewhat more corruption-prone (though you don't seem to have had that problem).  I would still recommend having a copy of the front-end on each user's local machine, for efficiency's sake, but if it works for you this way, more power to you.

    Dirk Goldgar, MS Access MVP
    Access tips: www.datagnostics.com/tips.html

    Thursday, June 11, 2015 11:31 PM
  • Actually I do copy it every time. Since the master front end is hosted on the same server share as the backend, if they can't copy the front end it means they wouldn't be able to work in the database even if they used their local front end copy. For laptops that might be used without access to the server, I gave them an option to make a readonly copy of the backend and then run that with the last front end they had copied.

    I don't remember ever having problems with this. It simplifies rolling out updates, eliminates front end bloat, and automatically recovers from any possible front end corruption.

    There are a number of utilities available, such as Tony Toews' Auto FE Updater or FMS's Total Access Startup, to copy the front-end from the server only when there's a new version to be deployed.  For that matter, I know lots of people who have implemented the same basic functionality using Windows script files.


    Dirk Goldgar, MS Access MVP
    Access tips: www.datagnostics.com/tips.html

    Thursday, June 11, 2015 11:35 PM
  • If your user ran a process that built a local table then logged out. The next time he used the database, you would re-copy the database and WIPE OUT his local table. Meanwhile the back-end data used to build the local table could have changed, making reproducing the results impossible. That could be disatrous. I use local tables in many of my applications so that would be a totally unworkable design for me.
    Monday, June 15, 2015 5:34 PM
  • I know this is an old thread, but how do you create a shortcut to download a new front end?


    TIA, Paul

    Monday, August 21, 2017 6:33 PM
  • The simplest way is to have the shortcut execute a program to download a new front-end if there's one available.  As mentioned above, two products that do this are Tony Toews' Auto FE Updater and FMS's Total Access Startup.  I don't know how much they cost, but I don't think they're expensive.  Tony's used to be free, but I don't think it is any more.

    A very simplistic approach would be to execute a .bat file that copies down the front-end from the master copy (stored on a network share) every time, and then starts the new copy, every time it is clicked.  A little more complicated would be to execute a VBScript file that could use a more sophisticated method to determine whether the master copy is a later version than the user's current front-end, and would only copy it down if that is so.


    Dirk Goldgar, MS Access MVP
    Access tips: www.datagnostics.com/tips.html

    Wednesday, August 23, 2017 3:32 PM
  • I know I'm necro-threading but I solved this issue by having a shortcut which points to a .bat file with RoboCopies the latest frontend to the (eg C:\Users\SNODGRASS) local folder on the computer they are using it on. The robocopy only copies if the file there is older or not the same as one already there. Now you can have multiple users using the application at the same time. It's also very easy to deploy an update by changing just one file.in "\Current Frontend".

    attrib -h "%userprofile%\OpNote2.accdb"

    robocopy "%cd%\Backend - Do not mess with\Current Frontend" "%userprofile%"  /xo /xx /fft /z /log+:"S:\TR13\SRU General\OpNote2\Backend - Do not mess with\log.log"

    rem /XO : eXclude Older - if destination file exists and is the same date or newer than the source - don’t bother to overwrite it.
    rem /FFT : Assume FAT File Times (2-second date/time granularity).

    attrib +h "%userprofile%\OpNote2.accdb"

    start "" "%userprofile%\OpNote2.accdb" /cmd "%cd%"

    Michael


    Thursday, September 17, 2020 9:50 AM