Results 1 to 7 of 7
  1. #1
    Lounger
    Join Date
    Sep 2005
    Posts
    31
    Thanks
    0
    Thanked 0 Times in 0 Posts
    XP Professional and Access 2007

    I have created a database for our users to create work orders for the facilities department. The database is sitting in a folder on a shared drive. The thought is that work orders are not going to be generated at a large volume so the need for acutally having something on every pc is not necessary. My problem that i am running into is that i have several users at remote locations from where the server resides that try and enter a work order and it takes a really long time or the program says "not responding". I have been reading several things on this site about splitting the database and while that sounds feasible i have some questions. If I split the database can i still have the one front end piece for all across the company to access and submit a workorder through? Will the network issues i seem to have at remote sites be helped by the splitting?

    Thanks

  2. #2
    Plutonium Lounger
    Join Date
    Mar 2002
    Posts
    84,353
    Thanks
    0
    Thanked 29 Times in 29 Posts
    It's best to give every user an individual copy of the frontend database, stored on his or her local hard disk. This will not solve the problems caused by the slow network, but it will decrease the probability of the frontend getting corrupted.

    (See WendellB's tutorial Why Split a Database?)

  3. #3
    4 Star Lounger
    Join Date
    Feb 2008
    Location
    United Kingdom
    Posts
    490
    Thanks
    0
    Thanked 0 Times in 0 Posts
    You should also uncheck the Name Autocorrect, this really slows down font/backend setups.

    The link will show you where to go to UNSELECT the function.

    http://msdn.microsoft.com/en-us/library/aa...office.10).aspx

  4. #4
    Lounger
    Join Date
    Sep 2005
    Posts
    31
    Thanks
    0
    Thanked 0 Times in 0 Posts
    [quote name='HansV' post='778251' date='03-Jun-2009 21:32']It's best to give every user an individual copy of the frontend database, stored on his or her local hard disk. This will not solve the problems caused by the slow network, but it will decrease the probability of the frontend getting corrupted.

    (See WendellB's tutorial Why Split a Database?)[/quote]

    suggestions for distributing a frontend to all users? and if updates are made to the frontend how are those distributed?

  5. #5
    Plutonium Lounger
    Join Date
    Mar 2002
    Posts
    84,353
    Thanks
    0
    Thanked 29 Times in 29 Posts
    See for example Mark Liquorman's Post 745537. Or ask WendellB about his DBLauncher (a commercial product).

  6. #6
    Super Moderator
    Join Date
    Aug 2001
    Location
    Evergreen, CO, USA
    Posts
    6,623
    Thanks
    3
    Thanked 60 Times in 60 Posts
    Let me add some additional suggestions for your remote user. The only viable solution we've found for WAN class users (i.e. those connection via DSL or cable modem), is to use a Remote Access tool and actually run the software on the server itself. In fact I work that way with all of my clients - my closest client is 100 miles away - the furtherest nearly 2000 miles. I use Remote Desktop or Windows Terminal Services for the work I do, but there are other products that work quite well. They range from PC Anywhere (Symantec), to web products like LogMeIn, and CITRIX which is a very robust package to support a large number of users.

    The problem with deploying the front-end to a remote workstation and then linking to the tables, is that the linking process itself takes considerable time, and updates to tables, especially to Access tables is still quite slow, as Access brings the table to the workstation to perform queries and such. Using a SQL Server back-end is somewhat better but still rather slow if you run queries that involve multiple joins. Especially if your remote workstations only need occasional access to the database, and can live with a minute or two connetion process when they do need access, I think you will find the Remote Access approach is the best solution. And even in that environment, give each user their own front-end rather than trying to share a single front-end.
    Wendell

  7. #7
    Lounger
    Join Date
    Sep 2005
    Posts
    31
    Thanks
    0
    Thanked 0 Times in 0 Posts
    [quote name='WendellB' post='778304' date='04-Jun-2009 02:57']Let me add some additional suggestions for your remote user. The only viable solution we've found for WAN class users (i.e. those connection via DSL or cable modem), is to use a Remote Access tool and actually run the software on the server itself. In fact I work that way with all of my clients - my closest client is 100 miles away - the furtherest nearly 2000 miles. I use Remote Desktop or Windows Terminal Services for the work I do, but there are other products that work quite well. They range from PC Anywhere (Symantec), to web products like LogMeIn, and CITRIX which is a very robust package to support a large number of users.

    The problem with deploying the front-end to a remote workstation and then linking to the tables, is that the linking process itself takes considerable time, and updates to tables, especially to Access tables is still quite slow, as Access brings the table to the workstation to perform queries and such. Using a SQL Server back-end is somewhat better but still rather slow if you run queries that involve multiple joins. Especially if your remote workstations only need occasional access to the database, and can live with a minute or two connetion process when they do need access, I think you will find the Remote Access approach is the best solution. And even in that environment, give each user their own front-end rather than trying to share a single front-end.[/quote]

    Thank you everyone for all your help. We are going to take the Remote Access approach - i didn't realize that some of our users have done this in the past with another database. Will still look into splitting the database. Thanks again.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •