Access-Datenbank auf SharePoint: warum das schiefgeht
Warum Mehrbenutzer-Access und Dokumentbibliotheken nicht zusammenpassenAccess-Datenbank auf SharePoint: warum das schiefgeht

|
WISSEN Alles zu CosyTrack.Drive: SharePoint, Teams und OneDrive als Laufwerksbuchstaben, am Arbeitsplatz und auf dem Terminalserver. |
BERATUNG Du willst wissen, was auf ein Laufwerk gehört und was in eine Datenbank? Wir sortieren das mit dir. |
SCHULUNG Onboarding für Admins: Laufwerksquellen, Rechte pro Laufwerk, Richtlinien und Admin-Kit. |
|---|
Die kurze Antwort: Eine Access-Datenbank (.accdb oder .mdb), mit der mehrere Personen gleichzeitig arbeiten, gehört nicht in eine SharePoint- oder OneDrive-Dokumentbibliothek. Das gilt für den Weg über den Sync-Client genauso wie für den Browser und für jedes Laufwerk, das auf eine Bibliothek zeigt. Microsoft schreibt selbst, dass du eine Access-Datenbank zwar in OneDrive oder einer SharePoint-Bibliothek speichern kannst, sie von dort aber nicht öffnen solltest: Die Datei wird unter Umständen lokal heruntergeladen, bearbeitet und wieder hochgeladen, und wenn mehrere Personen sie öffnen, können mehrere Kopien entstehen. Die saubere Lösung ist eine geteilte Datenbank, deren Tabellen in SQL Server, Azure SQL, Dataverse oder für einfache Fälle in SharePoint-Listen liegen.
Jede Firma hat sie: die Access-Datenbank, die ein Kollege 2008 an einem verregneten Wochenende gebaut hat und ohne die heute weder Kundenservice noch Lager funktionieren. Sie lag jahrelang friedlich auf \\fileserver\Abteilung, niemand hat sie je dokumentiert, und der Kollege ist längst im Ruhestand. Dann kommt das Projekt „Fileserver ablösen“, alles wandert nach SharePoint, und drei Wochen später fragt jemand, warum der Kunde Meier zweimal im System steht, einmal mit alter und einmal mit neuer Adresse. Oder warum die Datei jetzt „Kunden-PC07.accdb“ heißt.
Dieser Beitrag beantwortet genau eine Frage: Warum funktioniert das nicht, und was machst du stattdessen? Und weil wir sonst gern über Laufwerksbuchstaben schreiben, sagen wir hier ausdrücklich, wo auch ein Laufwerk nicht hilft.
|
FAKTEN · Was Microsoft dazu sagt Microsoft empfiehlt, eine Access-Datenbank nicht aus OneDrive oder einer SharePoint-Dokumentbibliothek heraus zu öffnen. Die Warnung gilt laut Microsoft für alle Arten von Access-Dateien, einzelne wie geteilte Datenbanken, und für die Formate .accdb, .accdc, .accde und .accdr. Als Gründe nennt Microsoft, dass die Datei zum Bearbeiten lokal heruntergeladen und nach dem Speichern wieder hochgeladen werden kann und dass beim Öffnen durch mehrere Personen mehrere Kopien der Datenbank entstehen können. Für das gemeinsame Arbeiten nennt Microsoft stattdessen die geteilte Datenbank auf einem Netzwerkordner, SharePoint-Listen und einen Datenbankserver wie SQL Server. |
|---|
Die Ursache: Access ist eine Datenbank, die sich als Datei verkleidet
Eine .accdb sieht im Explorer aus wie ein Word-Dokument: ein Symbol, ein Name, eine Größe. Innen ist sie aber eine vollständige Datenbank mit Tabellen, Indizes, Abfragen, Formularen und oft auch VBA-Code. Im Mehrbenutzerbetrieb öffnen mehrere Rechner gleichzeitig dieselbe Datei auf einer Dateifreigabe. Access legt daneben eine Sperrdatei an (.laccdb, bei älteren .mdb-Dateien .ldb) und schreibt Änderungen gezielt in einzelne Bereiche der Datei, während andere weiterlesen. Das funktioniert nur, weil eine Windows-Dateifreigabe genau diesen gleichzeitigen Zugriff auf dieselbe Datei unterstützt.
Eine Dokumentbibliothek ist anders gebaut. Sie speichert Dateien als Ganzes, mit Versionen, Metadaten und Berechtigungen. Für Word, Excel und PowerPoint gibt es eine eigene Mitbearbeitung, bei der die Office-Apps die Änderungen mehrerer Personen zusammenführen. Für Access gibt es diese Mitbearbeitung nicht. Aus Sicht der Bibliothek ist die .accdb eine große Binärdatei, die jemand hochlädt, und die nächste hochgeladene Fassung ersetzt die vorige.

Was dabei konkret passiert
Zwei Personen öffnen die Datenbank. Beide bekommen ihre eigene Kopie, beide erfassen Aufträge. Wer zuletzt speichert, lädt seine Kopie hoch. Im besten Fall bemerkt das System den Konflikt und legt eine zweite Datei an, im schlechtesten ist die Arbeit des anderen still überschrieben. Das ist kein Fehler von SharePoint und keiner von Access. Die beiden sind nur nicht füreinander gebaut. Wie SharePoint grundsätzlich mit Sperren und Konflikten umgeht, beschreibt Datei gesperrt, Konflikt, doppelte Kopie: gemeinsames Arbeiten in SharePoint.
|
Symptom |
Was dahintersteckt |
|---|---|
|
Doppelte Datensätze oder verschwundene Eingaben |
Mehrere Kopien wurden parallel bearbeitet und nacheinander hochgeladen |
|
Dateien wie „Datenbank-PC07.accdb“ oder „(1)“ |
Konfliktkopien aus der Synchronisierung |
|
Meldung, die Datenbank sei von einem anderen Benutzer geöffnet |
Sperrdatei .laccdb liegt verwaist in der Bibliothek oder in einer lokalen Kopie |
|
Lange Wartezeiten beim Öffnen und Speichern |
Die ganze Datei wird übertragen, auch wenn sich nur ein Datensatz geändert hat |
|
Datenbank muss repariert werden |
Unvollständig übertragene oder parallel geänderte Fassung |
|
WARNUNG · Komprimieren ist keine Rettung „Komprimieren und Reparieren“ kann eine beschädigte Datei manchmal wieder öffnen. Es führt aber keine Datensätze aus zwei Kopien zusammen. Wenn zwei Fassungen existieren, musst du die Unterschiede von Hand abgleichen. Und das macht genau so viel Spaß, wie es klingt. |
|---|
Sync, Browser oder Laufwerk: Der Weg ist egal
Gern hört man: „Mit dem Sync-Client geht es nicht, aber mit dem Browser schon.“ Oder: „Wir binden die Bibliothek einfach als Laufwerk ein, dann ist es wie früher.“ Leider nein. Alle drei Wege ändern nur, wie die Datei zum Rechner kommt. Sie ändern nicht, wo und wie sie gespeichert wird.

|
Zugangsweg |
Wie die Datei bearbeitet wird |
Folge für Access mit mehreren Benutzern |
|---|---|---|
|
OneDrive-Synchronisierung |
Jeder Rechner hat eine lokale Kopie, der Client lädt Änderungen hoch |
Mehrere Kopien, Konfliktdateien, überschriebene Eingaben |
|
Browser („In App öffnen“) |
Access hat keine Browser-Bearbeitung, die Datei wird heruntergeladen und nach dem Speichern wieder hochgeladen |
Wie bei der Synchronisierung, nur weniger sichtbar |
|
Explorer-Ansicht (WebDAV) |
Netzwerkpfad auf die Bibliothek, die Datei bleibt ein Dokument |
Keine Datenbankfreigabe im Sinne von Access, dazu ein veraltetes Verfahren |
|
Laufwerksbuchstabe auf eine Bibliothek |
Komfortabler Zugriff, der Speicher bleibt eine Dokumentbibliothek |
Gleiches Grundproblem: Die Bibliothek ist kein gemeinsamer Datenbankspeicher |
Zur Explorer-Ansicht und ihren eigenen Problemen findest du mehr in SharePoint im Explorer öffnen funktioniert nicht mehr. Einen Vergleich der Zugangswege für normale Dokumente liefert OneDrive-Sync, Explorer-Ansicht oder CosyTrack.Drive.
|
WICHTIG · Auch die geteilte Datenbank hilft hier nicht Manche teilen die Datenbank korrekt in Frontend und Backend und legen dann das Backend in die Bibliothek. Das verschiebt das Problem nur in die Datei mit den Tabellen, also genau dorthin, wo es am meisten wehtut. Microsofts Warnung gilt ausdrücklich auch für geteilte Datenbanken. |
|---|
|
AUS DER PRAXIS · Filialisierter Lebensmittelbetrieb Die Bestell-Datenbank wanderte beim Umzug mit in die Teams-Bibliothek der Disposition. Morgens bestellten vier Filialleitungen gleichzeitig. Mittags gab es drei Fassungen der Datei, und die Bestellung von zwei Filialen war in keiner davon vollständig. Die Übergangslösung war banal: Backend zurück auf die Dateifreigabe im Rechenzentrum, danach Umzug der Tabellen nach Azure SQL. |
|---|
Die saubere Lösung mit Microsoft-Bordmitteln
Die gute Nachricht: Du musst die Access-Anwendung nicht wegwerfen. Formulare, Berichte und VBA können bleiben. Was umziehen muss, sind die Tabellen. Dafür hat Microsoft drei Ziele, die sich in Aufwand und Einsatzzweck deutlich unterscheiden.

|
Ziel für die Tabellen |
Passt gut, wenn … |
Was du beachten musst |
|---|---|---|
|
SharePoint-Liste |
wenige einfache Tabellen, überschaubare Datenmengen, Team arbeitet ohnehin in Microsoft 365 |
Listengrenzen und Schwellenwert für Ansichten, eingeschränkte Datentypen und Beziehungen |
|
Dataverse |
die Anwendung später in Power Apps weiterleben soll, Daten mit Rollen und Geschäftsregeln |
Lizenzierung der Power Platform, nicht alle Datentypen werden übernommen |
|
SQL Server oder Azure SQL |
viele Benutzer, große Datenmengen, komplexe Abfragen und VBA |
Datenbankbetrieb, Sicherung und Rechte; Abfragen eventuell anpassen |
|
Übergang: Backend auf Dateifreigabe |
der Umzug braucht noch Zeit |
Nur im lokalen Netz, nicht über Cloud-Speicher; Microsoft nennt Grenzen bei Zuverlässigkeit, wenn viele gleichzeitig ändern |
Schritt für Schritt zu SQL Server oder Azure SQL
1. Bestand erfassen: Welche Datenbanken gibt es, wer arbeitet damit, wie groß sind sie, welche anderen Dateien greifen darauf zu, etwa Excel-Arbeitsmappen mit Datenverbindungen?
2. Sicherung ziehen: Eine Kopie der .accdb vom Stand vor dem Umzug, außerhalb der Bibliothek.
3. Datenbank teilen: Mit der Datenbankaufteilung in Access trennst du Frontend und Backend, falls das noch nicht geschehen ist.
4. Tabellen migrieren: Mit dem SQL Server Migration Assistant für Access überträgst du Schema und Daten nach SQL Server, Azure SQL Database oder Azure SQL Managed Instance.
5. Tabellen verknüpfen: Das Frontend greift über verknüpfte Tabellen auf den Server zu. SSMA kann die Verknüpfung direkt herstellen.
6. Frontend verteilen: Jede Person bekommt eine eigene lokale Kopie des Frontends, am Arbeitsplatz oder im Profil auf dem Terminalserver.
7. Testen und umschalten: Mit echten Benutzern prüfen, dann die alte Datei schreibgeschützt archivieren.
Die Werkzeuge und Schritte beschreibt Microsoft auf der Seite SQL Server Migration Assistant für Access bei Microsoft Learn.
Dataverse und SharePoint-Listen
Für Dataverse bietet Access einen eigenen Migrationsweg: Du exportierst die Tabellen nach Dataverse, Access verknüpft sie anschließend als externe Tabellen. Microsoft weist darauf hin, dass nur unterstützte Datentypen exportiert werden und dass du in Access und Power Apps dasselbe Konto verwenden musst. Die Originaltabelle bleibt in Access erhalten, bis du sie selbst entfernst.
SharePoint-Listen sind die leichteste Variante. Access kann Tabellen in Listen verschieben und als verknüpfte Tabellen weiterverwenden. Für eine Adressliste oder ein Inventar reicht das oft. Für ein Warenwirtschaftsmodell mit zwanzig verknüpften Tabellen eher nicht. Was bei großen Listen und Bibliotheken zu beachten ist, steht in SharePoint-Bibliothek mit mehr als 5.000 Elementen.
|
FAKTEN · Grenzen von Access selbst Laut den Spezifikationen von Microsoft ist eine Access-Datenbank (.accdb) auf 2 GB begrenzt, einschließlich aller Objekte und abzüglich des Platzes, den Access für Systemobjekte braucht. Wer sich dieser Grenze nähert, sollte das Backend ohnehin auf einen Datenbankserver verlegen. |
|---|
|
TIPP · Excel hängt oft mit dran Viele Access-Datenbanken werden aus Excel abgefragt oder füllen selbst Excel-Vorlagen. Nach dem Umzug zeigen diese Verbindungen ins Leere. Wie du solche Abhängigkeiten findest und reparierst, beschreibt Excel-Verknüpfungen und Makros nach der SharePoint-Migration. |
|---|
Wenn Fileserver und SharePoint für eine Weile nebeneinander laufen, ist die Dateifreigabe der natürliche Platz für das Access-Backend bis zum Umzug. Wie du diese Phase organisierst, zeigt Fileserver und SharePoint parallel betreiben. Für das Gesamtbild aus Websites, Bibliotheken und Listen hilft dir die SharePoint-Beratung.
Und CosyTrack.Drive? Ehrlich: nicht für die Mehrbenutzer-Datenbank
CosyTrack.Drive bindet SharePoint- und Teams-Bibliotheken sowie OneDrive als Windows-Laufwerksbuchstaben ein, am Arbeitsplatz genauso wie auf dem Terminalserver, wo jeder Benutzer seine eigenen Laufwerke bekommt. Der Speicher dahinter bleibt aber eine Dokumentbibliothek. Deshalb gilt für Drive dasselbe wie für jeden anderen Zugangsweg: Eine Access-Datenbank, mit der mehrere Personen gleichzeitig arbeiten, gehört nicht auf ein Laufwerk, das auf eine Bibliothek zeigt. Das sagen wir lieber hier als später im Supportfall.
Wofür Drive in diesem Szenario gut ist
Rund um jede Access-Anwendung gibt es Dokumente: Angebote und Lieferscheine als PDF, Exporte nach Excel, Berichte, Vorlagen, Handbücher. Diese Dateien gehören in eine Bibliothek, und dort sind sie über einen festen Laufwerksbuchstaben wie S: für alle erreichbar, auch für Fachanwendungen, die einen Pfad mit Laufwerksbuchstaben erwarten. Mehr dazu in Fachanwendungen, die einen Laufwerksbuchstaben brauchen.
Dokumente zur Anwendung: Exporte, PDFs und Vorlagen liegen in der Bibliothek, die als Laufwerk eingebunden ist.
Einzelbenutzer-Dateien: Was nur eine Person öffnet, ist in der Bibliothek ein Dokument wie jedes andere. Prüfe dein konkretes Szenario im Pilot mit deiner eigenen Umgebung.
Nachschlagelaufwerke: Berichtsarchive oder Handbücher bindest du pro Laufwerk nur lesend ein. Wie das funktioniert, steht in Nur lesen oder schreiben – Rechte pro Laufwerk.

Pro Laufwerk legst du fest, ob es nur lesend oder lesend und schreibend eingebunden wird. Schreiben umfasst Speichern, Umbenennen, Löschen und Ordner anlegen. Die Konfiguration verteilst du per Gruppenrichtlinie oder Intune, zum Testen gibt es zusätzlich die Konfigurations-App. Auf der Übersicht siehst du, welche Laufwerke ein Benutzer tatsächlich bekommt.

|
Inhalt |
Richtiger Ort |
Mit CosyTrack.Drive als Laufwerk? |
|---|---|---|
|
Access-Datenbank, mehrere gleichzeitige Benutzer |
SQL Server, Azure SQL, Dataverse oder SharePoint-Liste |
Nein |
|
Access-Frontend |
Lokal auf jedem Rechner bzw. im Benutzerprofil |
Nein, es gehört lokal |
|
Exporte, PDFs, Berichte, Vorlagen |
SharePoint- oder Teams-Bibliothek |
Ja |
|
Einzelbenutzer-Datei |
Bibliothek oder eigenes OneDrive, z. B. O: |
Ja, im Pilot prüfen |
|
Handbücher, Berichtsarchiv |
Bibliothek |
Ja, gern nur lesend |
Im Pilot prüfen statt hoffen
Bevor du Drive ausrollst, gehört die Bestandsaufnahme der Access-Dateien zum Pilot: Welche Datenbanken liegen in den Ordnern, die nach SharePoint wandern, und wer arbeitet damit? Die Installation läuft per MSI, ein Ersteinrichtungs-Assistent hilft beim Start, nach der Installation gibt es einen Testzeitraum. Das Admin-Kit liefert Verbindungsprüfung, Bereitschaftscheck mit Bericht und einen Stresstest mit Bericht als Abnahmeprotokoll. Den Ablauf beschreibt der Einführungsfahrplan für CosyTrack.Drive.

|
WARNUNG · Drive ist kein Umzugswagen Drive zieht weder Tabellen nach SQL Server um noch Dateien in Massen nach SharePoint. Erkennt Drive eine Massenkopie, weist es darauf hin. Für den Umzug vom Fileserver ist CosyTrack.Migrate zuständig, siehe Drive oder Migrate – Arbeiten ist nicht Umziehen. |
|---|
Du möchtest gemeinsam klären, welche Inhalte auf ein Laufwerk gehören und welche in eine Datenbank, oder brauchst ein Angebot für den Test? Dann ist die Beratung zu CosyTrack.Drive der richtige Startpunkt. Für Terminalserver-Grundlagen lies SharePoint als Laufwerk auf dem Terminalserver, für den Arbeitsplatz SharePoint als Netzlaufwerk am Arbeitsplatz einbinden.
FAQ: Access-Datenbank und SharePoint
Kann ich eine Access-Datenbank in SharePoint speichern?
Speichern ja, gemeinsam damit arbeiten nein. Microsoft empfiehlt ausdrücklich, Access-Datenbanken nicht aus OneDrive oder einer SharePoint-Bibliothek zu öffnen. Als Ablage für eine Sicherung oder ein Archiv ist die Bibliothek in Ordnung.
Warum funktioniert es mit einer einzelnen Person scheinbar?
Weil es dann nur eine Kopie gibt, die bearbeitet und wieder hochgeladen wird. Das Problem mit mehreren Kopien entsteht, sobald eine zweite Person die Datei gleichzeitig öffnet.
Hilft es, die Datenbank in Frontend und Backend zu teilen?
Das Teilen ist richtig, aber nur, wenn das Backend an einem geeigneten Ort liegt: auf einem Datenbankserver, in Dataverse, in SharePoint-Listen oder übergangsweise auf einer Dateifreigabe im LAN. Ein Backend in einer Dokumentbibliothek hat dieselben Probleme wie die ungeteilte Datei.
Ist ein Laufwerksbuchstabe auf die Bibliothek eine Lösung?
Nein. Ein Laufwerksbuchstabe ändert den Zugriff, nicht den Speicher. Das gilt für die Explorer-Ansicht und auch für CosyTrack.Drive.
Welches Ziel ist für die Tabellen das richtige?
Für wenige einfache Tabellen reichen SharePoint-Listen. Soll die Anwendung später in Power Apps weiterleben, ist Dataverse naheliegend. Bei vielen Benutzern, großen Datenmengen und komplexen Abfragen ist SQL Server oder Azure SQL die belastbarste Wahl.
Kann ich die Access-Oberfläche weiterverwenden?
Ja. Formulare, Berichte und VBA bleiben im Frontend, das über verknüpfte Tabellen auf das neue Backend zugreift. Abfragen und Code musst du nach der Migration testen und gegebenenfalls anpassen.
Was ist mit der Datenbank auf dem Terminalserver?
Auch dort gilt: Das Frontend liegt pro Benutzer lokal, das Backend auf einem Datenbankserver. Auf einem Terminalserver ist der Weg zum Server meist kurz, was der Leistung zugutekommt.
Fazit: Daten in die Datenbank, Dokumente in die Bibliothek
Eine Access-Datenbank mit mehreren gleichzeitigen Benutzern braucht einen Speicher, der gleichzeitige Zugriffe auf dieselbe Datei koordiniert. Eine Dokumentbibliothek kann das nicht, und Microsoft sagt das auch. Daran ändert weder der Sync-Client noch der Browser noch ein Laufwerksbuchstabe etwas. Der saubere Weg: Datenbank teilen, Tabellen nach SQL Server, Azure SQL, Dataverse oder für einfache Fälle in SharePoint-Listen verlegen, das Frontend lokal betreiben.
CosyTrack.Drive ist für alles drumherum da: Dokumente, Exporte, Vorlagen und Archive als Laufwerksbuchstabe, am Arbeitsplatz und auf dem Terminalserver gleichermaßen. Für das Team, das Drive betreibt, gibt es die Schulung und Onboarding für CosyTrack.Drive. Und die Datenbank aus dem Jahr 2008 bekommt endlich ein Zuhause, in dem Kunde Meier nur noch einmal existiert.
Dieses Consulting-Dokument steht als PDF zum Download bereit: https://www.boddenberg.de/ArtikelPdf/jede-firma-hat-sie.pdf — © Ulrich B. Boddenberg · boddenberg.de











