Multiple users on an Access sheet

[diberlee]

Hi,

I recently made a database that we will use to allocate appointments between a team of up to 30 in 2 different sites. I have tested it with 10 people in the same site using it and have had no issues so far.

One of our managers wants to know whether it is likely to cause issues with network usage/congestion. When we introduce it to the other site. I told her it is unlikely, but went to our IT department for their opinion. I got a reply simply stating that Access is not intended for this sort of task, and is only designed to have a couple of people using it at a time.

I'd like a second opinion, because I don't think that answer is even close to correct. I'll describe briefly how it works and what our set up is.

The database has 2 tables, one that stores the details of the clients we call (7 fields), and another that logs each contact attempt (6 field) and ensures no 2 users get the same entry. I have split the database, with the backend saved on one of our networked drives, and the frontend will be distributed in an email. (at present it is just an unsplit database stored on a network drive, but I don't think this will work well when 2 different sites are using it).

I think data throughput will be minimal, but I don't know how I'd go about checking that. Would you expect any issues with this being used by 30 people simultaneously?

Cheers

 

[CJ_London]

I have had 50 or 60 users using an Access backend successfully, but not necessarily concurrently and only for reviewing/reporting data, not inputting.

Access is supposed to be OK for up to 5 users but it really does depend on what they are doing. You could consider migrating the back end to SQL server which is the accepted solution for more users or locating the db on a Citrix (or similar) server.

If your users are connecting via VPN or wireless networking, the chances are performance will be way too slow.

I would suggest you trial it and see what happens

 

[diberlee]

Hi,

Thanks both of you for your replies.

CJ, it's good to hear that you've been ok with that many people even though circumstances are a bit different. I'm hoping with a couple of design changes this will work out OK.

I'm going to take Pat's hint about my monolithic table and split it into entries that are actually required for the current day and then keep historic entries separate since they're only really used for reports.

Sadly one of our sites does access through WAN and they're the larger of the 2 sites that will use this. I trialled with a few people from their site using it last night and there were no issues with save conflicts etc, so that's encouraging. There isn't much data being moved around. My client's table has a list of clients to call; 150-200 entries on most nights. I use VBA to check the contactEvents table to see if we've already dealt with that client or if we've contacted them within 10 minutes. If either of those is true the next entry is checked, when we find the next one to call their details are shown in a form. I don't suppose that equates to more than a few kbs per entry.

If it does fall on it's face I'll have to approach our IT department and see if they'll be willing to set up an SQL server as you both suggest. Shouldn't be a big deal for them.

I'll report bacvk here and let you know how it goes over the next few days as I add a few more people to the trial each night.

Cheers