How do I get multiple users use my Microsoft access database across computers at different locations

Dear Faraday,

Good day, and thank you for the detailed description of your issue.

I understand that you have built a Microsoft Access database that works well locally, and you would now like multiple users in different locations to use it remotely. As a forum moderator, I genuinely wish I could directly review your database design, network setup, and client requirements to recommend the exact best deployment model for you. Unfortunately, my role here is limited to providing general guidance and possible approaches that you can evaluate based on your specific needs.

From my research, Microsoft Access can support multiple users, but simply placing a single .accdb file online (for example, in OneDrive or a SharePoint document library) and letting remote users open it directly is not recommended. As multiple users doing so can create duplicate copies of the database and lead to unexpected behavior. Here are a few approaches you can consider:

Split the database into front-end and back-end

First step for a multi-user Access database is to split the database into a front-end (which contains forms, queries, reports, macros, and VBA code) and a back-end (which contains the tables and data). Each user then gets their own local copy of the front-end, which connects to the shared back-end. Benefits include:

• Improved performance, since only the data is sent across the network.
• Greater availability for record edits.
• Enhanced security through NTFS file system permissions.
• Improved reliability, since any corruption is typically limited to a single user's front-end.
• Flexible development, allowing you to update the front-end without disrupting access to the data.

You can use Access's built-in Database Splitter Wizard for this (Database Tools > Access Database > Split Database).

Host the front-end on a remote environment

For users in different locations, a practical Access-friendly approach is to host the Access front-end on a Remote Desktop Server, Citrix, Azure Virtual Desktop, or a similar environment. In this setup:

• The Access database runs in one controlled server environment.
• Users connect remotely to that environment.
• Database file operations are not transferred over long-distance internet connections.

This is generally better than placing the back-end on a shared drive and letting remote users connect over VPN, since Access is file-based and can perform poorly or risk corruption over unstable or slow remote connections.

For a more scalable long-term solution, you can keep Access as the front-end but move the tables and data to a proper database server, such as:

• SQL Server
• SQL Server Express (free)
• Azure SQL Database

This approach gives you:

• Much better performance and scalability (Azure SQL Database supports terabyte-sized databases, about 500 times the 2 GB limit of Access).
• Better concurrent editing and record locking.
• Stronger account-based security.
• Automatic recovery in the event of system failure.
• Server-based query processing to reduce network traffic.

For references:

Split an Access database | Microsoft Support

Ways to share an Access desktop database | Microsoft Support

For a more detailed architectural recommendation tailored to your organization, I would also recommend that the Global Admin in your organization open a service request with Microsoft Support. A technical support engineer can review your specific network setup, client requirements, and licensing situation to help you decide on the most appropriate deployment path. If needed, they can also escalate the case to a specialized team for deeper analysis. For detailed instructions on how to get support, please refer to Get support - Microsoft 365 admin. If you don't know who your IT administrator is, please refer to this article: How do I find my Microsoft 365 admin? - Microsoft Support 

For additional assistance, use this link to find the appropriate contact number from your region: Global Customer Service phone numbers - Microsoft Support 

I hope this information is helpful and provides you with a clear path forward. Please know that even though I can't directly intervene, directing you to the correct, specialized support is the most effective help I can provide from my position. Thank you for your patience and understanding. Please let me know if you need anything else.

If the answer is helpful, please click "Accept Answer" and kindly upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Perhaps coincidentally, Richard Rost, MS Access MVP, has posted a long article on Reddit discussing the use of SQL Server as a back end to Access in a forthright, honest way. He tells the story from the point of view of a working Access developer, i.e. nothing theoretical or speculative. I mention it because it is quite relevant to the topic of remote access to a central database.

Speaking as someone who's been developing and teaching Microsoft Access for over 30 years, the approach I'd recommend is to take it one step at a time.

First, split the database into a front end and back end if you haven't already. Get everything working reliably with the back end still in an Access database. That gives you a solid foundation before adding another layer of complexity.

Once that's working well, move the back end to SQL Server. Azure SQL is a great option, but there are also many web hosting providers that offer SQL Server databases at a much lower cost if that's a better fit for your budget. I use WinHost.

I generally recommend migrating the tables one at a time. After the tables are moved, you can gradually convert any queries that make sense into SQL Server views or stored procedures. There's no need to do everything all at once.

When you're finished, each user simply runs their own local copy of the Access front end, which connects to the centralized SQL Server database over the Internet.

It's a very common architecture, and it's one I've helped many developers implement over the years. It's straightforward conceptually, but it isn't a five-minute project. Plan on at least a weekend - or more - depending on how complex your database is. Take it one step at a time, test thoroughly after each change, and you'll save yourself a lot of headaches. There are plenty of articles, videos, and community resources available to help you through the process.

LLAP
RR

And thanks, George, for the mention.

Dear Faraday,

Thank you for your update, no need to apologize for the delay at all. It sounds like you have already made great progress by splitting the database, so you are on the right track for a multi-user setup.

Before I answer your questions, I want to be upfront: while I can research and share high-level guidance on each of your questions, I would also encourage you to lean on the more specialized communities I mention below, or open a support request with Microsoft Support directly, for the detailed step-by-step decisions. They will genuinely serve you better on the deeper architecture questions.

I would also gently point out that George Hepworth and Richard Rost, who commented on your original post above, are a well-known Volunteer Moderator and MVP respectively, both with deep Access expertise. Their comments are absolutely worth engaging with, as their guidance will likely go much further than mine on the Access-specific side.

Since your questions are quite specific and cover several different topics, this reply is going to be a bit long. I will address each of your questions one by one so it is easier to follow.

1.What is a Remote Desktop Server, and how do you use it?

At a high level, a Remote Desktop Server (RDS) is a Windows Server role that hosts applications (such as Access) and lets multiple users connect to it remotely from their own devices. Users see the app as if it were installed locally on their machine, while it actually runs on the central server. In a typical Access setup, the front-end is deployed on the RDS server, while the back-end sits either on the same server or on a nearby file server, so the file operations between them stay entirely inside the datacenter.

Your users would:

1. Sign in to the RDS server using their Windows credentials.
2. Launch your Access front-end from within the server session.
3. Work with the database as if it were on their own PC.
4. Disconnect when done, without ever downloading the database file locally.

The main benefit for your scenario is that the Access file and its back-end connection stay on the server, and only the UI stream (screen updates and keystrokes) travels across the network. This is much more reliable than trying to run Access directly over the internet.

For reference: Remote Desktop Services overview in Windows Server | Microsoft Learn

2.Pros and cons of using a Remote Desktop Server

Pros:

• Access runs much more reliably compared to remote users connecting over VPN or shared drives.
• Central management, one place to update the front-end for all users.
• Better security, since the database file never leaves the server.
• Supports true concurrent multi-user access without corruption risks.

Cons:

• Requires RDS licensing (Windows Server + RDS Client Access Licenses per user).
• Requires a properly sized server and infrastructure (network, storage, backup).
• Ongoing IT maintenance is needed (patching, monitoring, backups).
• Higher upfront cost compared to a shared drive setup.

For a small organization, Azure Virtual Desktop (AVD) is often a more cost-effective and flexible alternative, since you only pay for what you use, and Microsoft handles the underlying infrastructure.

For reference: What is Azure Virtual Desktop? - Azure - Azure Virtual Desktop | Microsoft Learn

3.Can you keep asking questions in this thread?

Yes, absolutely, you are welcome to continue posting follow-up questions here, and I will do my best to answer or point you in the right direction. That said, for the deep step-by-step work involved in migrating Access tables to SQL Server, I would strongly encourage you to also open a new post. The response there will be much faster and more specialized than what I can offer here.

4.Independent clients outside your organization

For clients outside your organization, yes, they would each need their own copy of the Access front-end, but they can all connect to a single shared back-end (SQL Server or SQL Server Express, if you go that route). The key considerations are:

• Connectivity: Each client needs a way to reach your SQL Server, either over the internet (which requires proper firewall, security, and public endpoints) or via a VPN.
• Security: Their credentials, permissions, and data isolation need to be carefully designed if they should not see each other's data.
• Licensing and support: You will need to plan for what you provide vs what they set up themselves.

Frankly, if you plan to serve multiple external client organizations, Azure SQL Database or a hosted SQL Server is generally a better architectural fit than trying to host your own SQL Server locally, since it removes most of the connectivity and security headaches. However, this does need proper planning around cost and data separation.

For reference: What is the Azure SQL Database service? - Azure SQL Database | Microsoft Learn

5.Microsoft Power Apps

Power Apps is a modern low-code platform where you can build cloud-based apps that connect to your data stored either in Microsoft Dataverse (the underlying data platform) or in other data sources such as SharePoint, Microsoft 365, Dynamics 365, or SQL Server. Apps built with Power Apps have a responsive design and can run seamlessly in a browser or on mobile devices (phone or tablet).

The main benefits are:

• Users access the app through a web browser or mobile app, no Access installation needed.
• Concurrent multi-user access is built in and reliable.
• No file corruption concerns (there is no .accdb file involved).
• Integrates natively with Microsoft 365, Teams, SharePoint, Outlook, and Dynamics 365.
• Microsoft Copilot in Power Apps can help you describe the app you want in natural language, and AI designs it for you.

The trade-offs are:

• Rebuilding your Access forms, queries, reports, and VBA logic in Power Apps is still a project. However, Microsoft does provide an official Access to Dataverse migration tool, which streamlines migrating tables, relationships, and data in just a few minutes.
• Licensing is per user, and can add up depending on the plan.
• The learning curve is real, though the platform is quite approachable once you get started.

The great thing about the migration path is that your existing Access forms and queries can continue to work uninterrupted against the migrated Dataverse tables via linked tables. This means you can migrate the data first, then rebuild the front-end in Power Apps gradually, without disrupting your existing users.

If you are open to rethinking the architecture rather than continuing to build on Access, Power Apps is genuinely one of the strongest paths forward for a small organization looking to modernize.

For references:

What is Power Apps? - Power Apps | Microsoft Learn

Copilot in Power Apps overview - Power Apps | Microsoft Learn

Get started: Migrate Access data to Dataverse | Microsoft Support

Access Migration to Power Apps and Dataverse GA announcement

For truly detailed guidance on Access architecture, SQL Server migration, and Power Apps design, these are the communities that will serve you best:

• Microsoft Q&A Access category (where you already are), continue engaging with George and Richard's comments above.
• Power Platform Community for Power Apps, Power Automate, and Dataverse questions.
• Microsoft Q&A SQL Server category for SQL Server migration questions, which is well-monitored by SQL specialists.

I hope this points you in the right direction. Please let me know if you need anything else, and best of luck with the next phase of your project.

If the answer was helpful, please consider clicking “Yes” and giving it an upvote. This small action can make a big difference by helping others with similar questions find this solution more easily.