Waar sla je je Access-data op? Een eerlijk overzicht.
Als je met MS Access werkt en meerdere mensen moeten tegelijk bij dezelfde data kunnen, komt er een moment dat je jezelf afvraagt: waar zet ik de backend eigenlijk neer? OneDrive? Een netwerkschijf? SharePoint? Of toch een SQL Server?
Ik heb dit de afgelopen tijd uitgezocht. Dit is wat ik tegenkwam.
De verleiding van OneDrive
Het lijkt logisch. Iedereen heeft toegang, het is makkelijk in te stellen en je hoeft niets extra’s te regelen. Zet je .accdb bestand in OneDrive, klaar.
Maar hier gaat het mis.
Access maakt bij elke open sessie een .laccdb lockfile aan naast je database. Die lockfile coördineert wie welk record heeft. Op een gewone netwerkschijf werkt dat prima. Op OneDrive niet – want OneDrive is geen netwerkschijf, het is een sync-client. Die lockfile wordt niet real-time gesynchroniseerd. Twee gebruikers kunnen tegelijk denken dat zij exclusieve toegang hebben.
Het gevolg? Datacorruptie. En niet het soort waar je een leuke anekdote aan overhoudt.
Daarnaast synchroniseert OneDrive bestanden in blokken, niet als atomische schrijfoperaties. Als Access midden in een schrijfactie zit terwijl OneDrive tegelijk synchroniseert, kun je je database beschadigen. Microsoft raadt dit scenario officieel af. Dat zegt genoeg.
Een netwerkschijf dan?
Voor een klein team dat altijd op kantoor zit, werkt dit prima. Access is hier eigenlijk voor gebouwd. De lockfiles doen hun werk, verbindingen zijn stabiel en de performance is acceptabel.
Maar zodra mensen ook thuis werken, krijg je een probleem. Thuiswerkers hebben dan altijd VPN nodig om bij de netwerkschijf te kunnen. En VPN-verbindingen zijn te instabiel voor Access-bestandstoegang. Een korte onderbreking – even verbinding weg, even terug – en Access raakt de verbinding met de backend kwijt. In het slechtste geval raakt de database corrupt.
Dit is iets waar ik aan moest wennen. Vroeger was een netwerkschijf de standaard. Maar hybride werken heeft die aanname definitief onderuitgehaald.
SharePoint-lijsten als backend
Dit is wat veel mensen doen als ze Access willen combineren met hybride werken. Je koppelt de tabellen in Access aan SharePoint-lijsten via de externe gegevens-functie. Geen VPN nodig, werkt thuis en op kantoor.
Het werkt. Maar het heeft beperkingen die je vroeg of laat gaat raken.
SharePoint-lijsten hebben een limiet van 5.000 items per weergave zonder speciale indexering. Bij grotere datasets moet je daar omheen werken, wat omslachtig is. Complexe relaties en queries zijn trager dan bij een echte database. En het authenticatiegedrag – iedereen die met Access en SharePoint werkt kent het: het inlogscherm dat steeds terugkomt, zeker als mensen wisselen tussen thuis en kantoor.
Voor een klein team met lichte data is het een acceptabele oplossing. Voor 10-25 gebruikers met regelmatige updates wordt het al snel een bron van frustratie.
SQL Server: de juiste keuze
Als je serieus multi-user werkt met Access, is een SQL Server backend de enige oplossing die echt schaalt. Access blijft gewoon de frontend – je relinkt de tabellen via ODBC. Vanuit de gebruiker verandert er nauwelijks iets.
De vraag is welke variant je kiest.
SQL Server Express is gratis en geschikt tot 10GB aan data. Prima voor kleinere organisaties. Nadeel: je hebt een server nodig die altijd aan staat, en beheer is je eigen verantwoordelijkheid.
SQL Server Standard kost ongeveer €900 per jaar en is geschikt als je meer capaciteit of geavanceerdere functies nodig hebt.
Azure SQL Database is wat ik zou aanraden voor hybride teams. Je betaalt per gebruik – voor een team van 10-25 personen met gemiddeld gebruik kom je uit op ruwweg €25-60 per maand. Geen eigen server nodig. Geen VPN vereist. Microsoft regelt de backups, de updates en de beschikbaarheid.
De migratie is minder ingewikkeld dan het klinkt:
- Azure SQL database aanmaken via de Azure Portal
- Tabelstructuur en data overzetten met de gratis SQL Server Migration Assistant
- ODBC-verbinding instellen op elke pc
- Tabellen in Access herlinken naar de nieuwe ODBC-bron
Dat is het. De Access frontend hoeft nauwelijks aangepast te worden.