3
Access 2003 und Windows 7 Datensatzsperrung aufheben?
Hallo,
wir haben folgendes Problem bei einem Kunden.
Altsystem war: Windows XP Umgebung und Office 2000
Verwendet wird eine Hauptdatenbank (Access .mdb) in der die gesamten Kundeninformationen gepflegt werden - diese wurde scheinbar damals eigens für Office 2000 programmiert.
Wir sind gerade dabei den Kunden auf Windows 7 Umgebung zusammen mit Office 2003 umzustellen. Wir mussten auf Office 2003 zurück greifen, da die Datenbank weder unter 2007 noch 2010 arbeitet.
Die .mdb liegt auf einer NAS. Sobald die .mdb bei einem User geöffnet ist, wird eine temp. Datensatzsperrung (.ldb) geschrieben und kein weiterer user bekommt die Datenbank geöffnet.
Wir bekommen wr das abgestellt? Gibt es eine Möglichkeit, parallel darin zu arbeiten?
Vielen Dank schon einmal im Voraus.
Gruß,
Benny
wir haben folgendes Problem bei einem Kunden.
Altsystem war: Windows XP Umgebung und Office 2000
Verwendet wird eine Hauptdatenbank (Access .mdb) in der die gesamten Kundeninformationen gepflegt werden - diese wurde scheinbar damals eigens für Office 2000 programmiert.
Wir sind gerade dabei den Kunden auf Windows 7 Umgebung zusammen mit Office 2003 umzustellen. Wir mussten auf Office 2003 zurück greifen, da die Datenbank weder unter 2007 noch 2010 arbeitet.
Die .mdb liegt auf einer NAS. Sobald die .mdb bei einem User geöffnet ist, wird eine temp. Datensatzsperrung (.ldb) geschrieben und kein weiterer user bekommt die Datenbank geöffnet.
Wir bekommen wr das abgestellt? Gibt es eine Möglichkeit, parallel darin zu arbeiten?
Vielen Dank schon einmal im Voraus.
Gruß,
Benny
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 179121
Url: https://administrator.de/forum/access-2003-und-windows-7-datensatzsperrung-aufheben-179121.html
Ausgedruckt am: 23.12.2024 um 20:12 Uhr
3 Kommentare
Neuester Kommentar
Wenn die Verwaltung und Daten in einer MDB liegen, wirds ein Problem. Das geht aus der Frage leider nicht hervor. Wenn dem so ist, muss die Access - Anwendung in Frontend und Backend gesplittet werden, das Backend liegt auf dem Server, mit dem Frontend arbeiten die User. Alternativ wäre es auch möglich, die Daten z.B. in eine Mysql - Datenbank zu schieben und die Tabellen dann in MS Access zu verknüpfen. Persönlich würde ich immer die Lösung mit MySQL vorziehen, da ein Backend mit vielen Daten ggf an seine physikalischen Grenzen stößt und dann irgendwann gar nichts mehr geht. Ohne weitere Infos kann ich leider nur so allgemeine Hilfe bieten.
P.S. Meine Vorliebe für Mysql sei mir verziehen, war aber nur als Beispiel gedacht, MS Sql - Server oder eine andere DB geht auch, so lange man Access dazu überreden kann, sich mit der jeweiligen DB zu verbinden.
Beste Grüße
Frank
P.S. Meine Vorliebe für Mysql sei mir verziehen, war aber nur als Beispiel gedacht, MS Sql - Server oder eine andere DB geht auch, so lange man Access dazu überreden kann, sich mit der jeweiligen DB zu verbinden.
Beste Grüße
Frank
Moin Moin,
wie Ihr schon festgestellt habt, geht eine alte 2000er Datenbank nicht mehr mit 2007/2010. Das ist so gewollt von M$ und mehrfach dokumentiert.
Ich kann auch Frank nur zustimmen, in einer Netzwerkumgebung sollte man immer in Frontend (mit dem Programm) und Backend (mit den Tabellen) aufteilen.
Was du nun tun musst:
- Starte Access 2010 (oder 2007)
- erstelle eine leere Datenbank
- importiere alle Objekte (bis auf die Tabellen) der alten 2000er Datenbank
- speichere diese neue Datenbank als Frontend ab
- schließe die Frontend - accdb
- erstelle eine zweite leere Datenbank
- importiere alle Tabellen der alten 2000er Datenbank
- speichere diese neue Datenbank als Backend ab
- schließe die Backend - accdb
- kopiere nun die neue Backend - accdb auf den Server
- öffne nun noch mal die Frontend - accdb
- verknüpfe nun die Tabellen aus der Backend - accdb mit dem Frontend
- schließe die Frontend - accdb
- kopiere nun die Frontend - accdb auf alle Clients
Ich setzte jetzt mal voraus, dass beim Importieren keine Fehler aufgetreten sind
Start also auf dem Client-PC das dort installierte Access 2010 (ich würde die kostenlose Runtime empfehlen)
In den Grundeinstellungen legst du nun fest, dass dieser User KEINEN exklusiven Zugriff auf Datenbanken hat. (btw gilt das auch für 2003)
Diese Einstellung ist pro Client notwendig!
fertig
Grüße aus Rostock
Wolfgang
(Netwolf)
(Edit) eine NAS als Speicherort für eine Datenbank ist nicht sinnvoll, da zu langsam!!!
Optimal wäre:
pro Datenbank eine eigene Partition
auf einer sehr schnellen Festplatte (SSD)
mit viel RAM-Speicher beim Client
wie Ihr schon festgestellt habt, geht eine alte 2000er Datenbank nicht mehr mit 2007/2010. Das ist so gewollt von M$ und mehrfach dokumentiert.
Ich kann auch Frank nur zustimmen, in einer Netzwerkumgebung sollte man immer in Frontend (mit dem Programm) und Backend (mit den Tabellen) aufteilen.
Was du nun tun musst:
- Starte Access 2010 (oder 2007)
- erstelle eine leere Datenbank
- importiere alle Objekte (bis auf die Tabellen) der alten 2000er Datenbank
- speichere diese neue Datenbank als Frontend ab
- schließe die Frontend - accdb
- erstelle eine zweite leere Datenbank
- importiere alle Tabellen der alten 2000er Datenbank
- speichere diese neue Datenbank als Backend ab
- schließe die Backend - accdb
- kopiere nun die neue Backend - accdb auf den Server
- öffne nun noch mal die Frontend - accdb
- verknüpfe nun die Tabellen aus der Backend - accdb mit dem Frontend
- schließe die Frontend - accdb
- kopiere nun die Frontend - accdb auf alle Clients
Ich setzte jetzt mal voraus, dass beim Importieren keine Fehler aufgetreten sind
Start also auf dem Client-PC das dort installierte Access 2010 (ich würde die kostenlose Runtime empfehlen)
In den Grundeinstellungen legst du nun fest, dass dieser User KEINEN exklusiven Zugriff auf Datenbanken hat. (btw gilt das auch für 2003)
Diese Einstellung ist pro Client notwendig!
fertig
Grüße aus Rostock
Wolfgang
(Netwolf)
(Edit) eine NAS als Speicherort für eine Datenbank ist nicht sinnvoll, da zu langsam!!!
Optimal wäre:
pro Datenbank eine eigene Partition
auf einer sehr schnellen Festplatte (SSD)
mit viel RAM-Speicher beim Client
Hallo,
vielen Dank für die sehr ausführlichen und schnellen Rückmeldungen.
Das bei dem Kunden nur eine NAS im Einsatz ist, kommt daher, dass dieses Büro nur zwei Arbeitsplätze beinhaltet und ausser dieser DB nur mit .doc und .xls Files gearbeitet wird.
Selbst ein kleiner Server wäre dort vollkommen fehl am Platze....
Aber dennoch werde ich die Anleitung mal abarbeiten
VG
Benny
vielen Dank für die sehr ausführlichen und schnellen Rückmeldungen.
Das bei dem Kunden nur eine NAS im Einsatz ist, kommt daher, dass dieses Büro nur zwei Arbeitsplätze beinhaltet und ausser dieser DB nur mit .doc und .xls Files gearbeitet wird.
Selbst ein kleiner Server wäre dort vollkommen fehl am Platze....
Aber dennoch werde ich die Anleitung mal abarbeiten
VG
Benny
