Search this and almost everything you find explains how to repair the file: Compact and Repair, import the objects into a fresh database, or buy a recovery tool. All of that is about the aftermath. None of it answers the question you actually asked, which is why it keeps happening — and Microsoft answers that plainly, in a document most of those pages never link.
If several people open one .accdb sitting on a network share, every one of them has the whole database open across the network — forms, queries, reports and tables alike. A dropped connection, a laptop that sleeps, a switch that hiccups, someone closing the lid mid-write: any of those can interrupt a write to the one file everybody is holding.
Microsoft’s own recommendation is unambiguous: “Consider splitting any database that several people share over a network. Splitting a shared database can help improve its performance and reduce the chance of database file corruption.”
Read that the other way round and it is the answer to your question: an unsplit database shared over a network has a higher chance of corruption, by the vendor’s own account. It is not bad luck and it is not your hardware.
Splitting turns one file into two: a back end holding only the data tables, which stays on the share, and a front end holding the forms, queries and reports, which each person keeps a local copy of on their own PC. Microsoft describes the arrangement as “a back-end database that contains the data tables, and a front-end database that contains all the other database objects”, with each user working through “a local copy of the front-end database”.
Three consequences, all in Microsoft’s words:
That last sentence is worth sitting with. Splitting does not stop corruption happening; it changes what gets corrupted. Instead of the shared file everybody depends on, it is one person’s local copy of the forms — which you replace by copying the front end down again. The data survives.
One detail people miss when they do split: Microsoft advises pointing at the back end using “the UNC path of the location instead of using a mapped drive letter”. Drive letters differ per machine, and a link that resolves on your PC and not on somebody else’s is a reliable way to reintroduce the problem you just fixed.
Splitting is the right first move, and it is not unlimited headroom. Microsoft’s published specifications put hard numbers on where Access stops:
The 255 figure is the one that gets quoted as reassurance, and it is misleading in practice: it is a ceiling, not a working figure. Long before it, a shared back end over a busy network starts behaving the way you are already complaining about.
If your database is a genuine Access application — VBA, complex reports, a form layer people are trained on — splitting is the correct fix and you should do it today.
It is a delay when the thing you have is not really an Access application at all: a handful of tables, a few forms, and a group of people who each need to update their own records from wherever they happen to be. That case ends up on a file share only because that is where Access put it, and every symptom — corruption, locking, the 2 GB line, the person who cannot get in from home — is downstream of storing shared records in a document on a network drive.
We build Bionic Forms and we would like Access owners in that second case to consider it, so this is not neutral. What we can offer instead of neutrality is that every limitation above is Microsoft’s own documentation rather than our characterisation, and that we will say plainly where we help and where we do not.
Where we help: there is no shared file to corrupt, because there is no shared file. Records live in a real database with per-person permissions and their own history, so two people editing different records never collide, and “who changed this and to what” has an answer. People outside your organisation can fill in a form without an account at all.
Where we do not: we do not run VBA, and we will not pretend a decade of Access macros ports across — if that logic is the product, moving is a rewrite and you should price it as one. We also do not read an .accdb directly: today the route in is a CSV export, which means the relationships have to be rebuilt from the key columns you exported. Our loader does rebuild them, and it refuses rather than guesses when a value is ambiguous, but it cannot recover a link you did not export.
Sourcing, plainly: every quotation comes from Microsoft’s own Office support documentation — split an Access database and Access specifications — checked on 21 August 2026. Where we describe the effect of unstable networks we are describing ordinary file behaviour rather than quoting a document, and we say so rather than dressing it up as a citation.
Being straight about where we are: Bionic Forms is pre-launch. There is no Windows desktop app yet and no iOS or Android app; the macOS and Linux desktop builds and the web app are what exist today, and we have no external customers to point at.
If you would rather not rebuild it by hand: tell us what your Access database does and we will build a working version and show you. No fee and no card — what we build fits the free plan, and we ask you to pay only once it is genuinely running your business.