Results 1 to 12 of 12
  1. #1
    Join Date
    Feb 2010
    Location
    Yorkshire UK
    Posts
    76

    Unanswered: Access across a network

    Hi,
    I have 10 users all using my application across the network. I have split the application into 2 databases.

    1. Live.mdb Has all forms reports etc
    2. Tables.mdb Has all the tables

    Both on the f:\ drive on the server.

    I am always tinkering with a copy of LIVE.MDB and at the end of the day, when everyone has logged out, I copy my updated LIVE.MDB onto the server.

    When someone is logged into the LIVE.MDB, I can see this by the padlock icon in the f:drive.

    Sometimes, machines are left on at night and before I can update, I have to go around each pc and see who is still logged in and log them out.

    Is there anyway of finding out which machine is logged in?

    Is there a way to force everyone out of the application from my machine?

    Thanks
    Simon

  2. #2
    Join Date
    Aug 2009
    Location
    Up Nort' Wi
    Posts
    140
    Better yet, use PKStormy's clone script. I've been using it for multiple dbs now and it's a friggin lifesaver...works better than the "auto-updaters" I've found. It's fairly easy to change the paths to suit your needs...the instructions and code are in the attached link.

    http://www.dbforums.com/6274786-post19.html

    Sam, hth
    Good, fast, cheap...Pick 2.

  3. #3
    Join Date
    Feb 2010
    Location
    Yorkshire UK
    Posts
    76
    Wow! I am often impressed with the help and knowedge here but this is brilliant. Works like a dream.

    Thanks again for your help.

    Simon

  4. #4
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    Quote Originally Posted by Jabber View Post
    I have split the application into 2 databases.

    1. Live.mdb Has all forms reports etc
    2. Tables.mdb Has all the tables

    Both on the f:\ drive on the server.
    If by this you mean that multiple users are using a single copy of the front end, which resides on the server, you're defeating the whole purpose of splitting the database, and sooner or later are going to come a cropper, as our British friends would say!

    The proper way of deploying a split database is to have a copy of the front end on each user's hard drive.
    Last edited by Missinglinq; 05-13-10 at 10:44.
    Hope this helps!

    The problem with making anything foolproof...is that fools are so darn ingenious!

    All posts/responses based on Access 2003/2007

  5. #5
    Join Date
    Feb 2010
    Location
    Yorkshire UK
    Posts
    76
    My users are not very IT literate. I could not e-mail them a copy and ask them to use it as they would struggle to even save the file to their desktop. I would have to visit each machine and do it for them. PKStormy's clone script is very useful. I think I will put the tables and the main application back into one database and leave this on the server and allow each user to use their own cloned version of it.

  6. #6
    Join Date
    Feb 2010
    Location
    Yorkshire UK
    Posts
    76
    On 2nd thoughts, I have to have the tables and the main database seperate or the cloning will not work.

  7. #7
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    Are you willing to trade ease of use for stability and reliability?

    How big of a problem will it be when your wan-shared access database becomes corrupt and unusable under concurrent usage?
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  8. #8
    Join Date
    May 2010
    Posts
    601
    Quote Originally Posted by Jabber View Post
    My users are not very IT literate. I could not e-mail them a copy and ask them to use it as they would struggle to even save the file to their desktop. I would have to visit each machine and do it for them. PKStormy's clone script is very useful. I think I will put the tables and the main application back into one database and leave this on the server and allow each user to use their own cloned version of it.
    PKStormy's clone script is design for having a copy of the front end on the local hard drive. It makes a new copy each time so that it automatically deploys updates to the workstation.

    If you want an easy to deploy solution, even via email, I would recommend checking out this very popular solution:

    Auto Fe Updater
    Boyd Trimmell aka HiTechCoach HiTechCoach.com (free access stuff)
    Microsoft MVP - Access Expert
    BPM/Accounting Systems/Inventory Control/CRM
    Programming: Nine different ways to do it right, a thousand ways to do it wrong.
    Binary--it's as easy as 1-10-11

  9. #9
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    Just to reiterate what Teddy said, because it cannot be stressed too much, if you continue with this strategy, sooner or later you are going to suffer a major meltdown of your database, quite possibly an unrecoverable one!
    Hope this helps!

    The problem with making anything foolproof...is that fools are so darn ingenious!

    All posts/responses based on Access 2003/2007

  10. #10
    Join Date
    Feb 2010
    Location
    Yorkshire UK
    Posts
    76
    I understand exactly what you are saying but I am now using PKStormy's clone script which is a design for having a copy of the front end on the local hard drive.

    So each user is now opening their own copy rather than all going into the one version on the server.

    Would this be OK?

    Simon

  11. #11
    Join Date
    May 2010
    Posts
    601
    Quote Originally Posted by Jabber View Post
    I understand exactly what you are saying but I am now using PKStormy's clone script which is a design for having a copy of the front end on the local hard drive.

    So each user is now opening their own copy rather than all going into the one version on the server.

    Would this be OK?

    Simon
    That is great.

    that is the method we have been urgung you to use.
    Boyd Trimmell aka HiTechCoach HiTechCoach.com (free access stuff)
    Microsoft MVP - Access Expert
    BPM/Accounting Systems/Inventory Control/CRM
    Programming: Nine different ways to do it right, a thousand ways to do it wrong.
    Binary--it's as easy as 1-10-11

  12. #12
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    The really quirky thing about using a shared front end is that many people report using them for extended periods, sometimes for years, without encountering any problems, and then suddenly they start experience all kinds of problems, including repeated corruption.

    Glad you have it set up correctly, now!
    Hope this helps!

    The problem with making anything foolproof...is that fools are so darn ingenious!

    All posts/responses based on Access 2003/2007

Posting Permissions

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