Results 1 to 7 of 7
  1. #1
    Join Date
    Nov 2003
    Posts
    6

    Unanswered: How Many Concurrent Users Can Access Support?

    Microsoft claims that MS Access can support up to 25 users with Access running on a file server system. I don't want to spend a lot of money for a DB server, if I don't have to.

    As anyone pushed the envelope past 25 workstations while running Access on a server? What would you say is a realistic limit- I don't exactly Microsoft's figure.

  2. #2
    Join Date
    Oct 2003
    Location
    Boston, Mass. USA
    Posts
    81
    It all depends ...

    How many records will this have? will it be a heavy use database or light use?

    How likely is it that everyone will be using it at the same time?

    If it is say just a lookup for staff phnee numbers this would probably be light use. but if, for example, you are wanting to track billable time spent in 5 minute increments for an office with multiple attorneys ... that would be much heavier use. especially if you want staff to be updating the logs as they go throughout the day.

    Mark

  3. #3
    Join Date
    Nov 2003
    Posts
    6
    Thanks for responding, Mark.

    The database consists of customer records and contact info, and the sales team consists of 25 people. They're not all going to be using the db concurrently, but there could be situations where 10-15 users make updates at the same time.

    I'm guessing this constitutes light use. Some people have told me that even with light use, they ran into trouble running Access on a file server. I don't know if they set it up right, but this disturbed me a little bit.

    I have looked into other cheap DB solutions, like Act! 6.0 (which apparently has a CRM component, which is nice) but the amazon.com reviews were unfavorable.





    Originally posted by mdr02125
    It all depends ...

    How many records will this have? will it be a heavy use database or light use?

    How likely is it that everyone will be using it at the same time?

    If it is say just a lookup for staff phnee numbers this would probably be light use. but if, for example, you are wanting to track billable time spent in 5 minute increments for an office with multiple attorneys ... that would be much heavier use. especially if you want staff to be updating the logs as they go throughout the day.

    Mark

  4. #4
    Join Date
    Jul 2002
    Location
    Romania
    Posts
    122
    25 users sounds fine. When you approach 50, you should consider switching to a client-server solution.

    If you use Access, follow the following 'directives':

    1. split the database (front-end/back-end)
    2. use the record-locking strategies appropriately
    3. use dynasets only when you need them
    4. kill all object variables in code as soon as you don't need them anymore
    5. don't put too many bells and whistles in the application, only what's absolutely necessary.
    6. (extremely important) Backup the database file as often as you can


    Remember: A poor design would render a database unusable even for 2 users. And you can't say it was because of Access...

    HTH

  5. #5
    Join Date
    Oct 2003
    Location
    Boston, Mass. USA
    Posts
    81
    one key point regarding splitting front end and back end that is often not mentioned in documenting is that the front end should be on the users machines, not on the server.

    If you have both the front end and back end on the server this could cause some problems, such as slow updates. This may sound simple, but unfortunately for people who know it is so obvious that they (including Microsoft white papers) don't mention it. but if you don't know -- especially if hardware, servers, etc. is not your thing - then you don't know, and not knowing can cost you hours of frustration.

    Having FE and BE on the server * CAN * be done successfully, if you have to, but I wouldn't recommend it. The problem with having FE on users machines is deploying updates - you either need a self-install utility or good support from IT unless you want to run around to everyone's desk yourself every time you release a patch. For running a beta during development with a few users you could probably get by with having he FR on the server. Or at least you could try, it could save some time.

    Also if you perceive this as something that will grow -- your database more complex your staff bigger, etc. you may want to consider SQL Server. Not necessarily right away, perhaps, but in your long-range planning don't assume it will always stay in Access. It may be easier to be talking with managment about eventually going to SQL server from day one rather than waiting to mention it when the need is urgent. Especially if that would require the cost of an outside programmer.

    Mark
    Last edited by mdr02125; 11-05-03 at 17:18.

  6. #6
    Join Date
    Oct 2003
    Posts
    66
    I concur with several of the above mentioned things. We have an Access DB that has up to 80 users. Only maybe 25-30 might be using at once. It is split into a front-end and back-end and still runs slow sometime almost unusably slow. We are migrating to an SQL Server to solve the issue. I suggest if it will be used heavily by mutiple users then it better be perfectly optimised or just done on SQL Server. Sometime forms will take minutes to open...

  7. #7
    Join Date
    Oct 2003
    Posts
    66
    oops forgot one important thing....
    Execute the compact and repair command nightly after a backup is done. You can write a quick batch file to do this. This will greatly speed up things...after a while if it is not done things will slow drastically.

Posting Permissions

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