Ich habe ein Problem mit ADO + Access-Datenbank. Anbindung und alles funktioniert einwandfrei, allerdings stehe ich jetzt vor der Frage, ob ich die *.mdb auf einen Server laden kann und somit mehreren Clienten (Schreib)Zugriffe erlaube kann. Vorher hab ich mit der BDE + Paradox gearbeitet - und da war es so, dass man eine Meldung bekommen hat, wenn ein bestimmter Datensatz in Bearbeitung war.

Ist sowas mit der Access-Datenbank auch moeglich? Ich hab mal lokal eine Access-DB mehrfach mit meinem Programm geoeffnet. Den selben Record veraendert und das Programm geschlossen... Das Resultat? Die Aenderungen des Programms, welches als letztes geschlossen wird schreibt seine Aenderungen in die DB... Sowas darf aber nicht passieren.

Was ich mir gedacht hab. Sobald ein Programm die Datenbank in den Edit-Modus setzt, sollte der Record fuer andere Clients unzugaenlich sein - zur Not die ganze Datenbank (allerdings gibts da wieder ein Problem, weil die DB ja vielleicht schon geoffnet ist... Dann darf der 2. Client eben keine Edit-Erlaubnis fuer die ganze DB bekommen).
Wenn die Aenderungen geschrieben wurden, dann soll Record bzw. Datenbank wieder freigegeben werden. Ist sowas moeglich?

Hoffentlich... Sonst fuehrt nur der Weg an einer Client/Server Anwendung vorbei... Denke ich.

Vielen Dank schonmal

OK, ich hab mir jetzt folgendes gedacht:

Ich werde einfach eine neue Tabelle in die Access-DB einfuegen, die den Status aller anderen Tabellen beinhaltet...
Wird nun ein EDIT oder ON NEW RECORD auf eine Tabelle gesetzt, schreibt der Client einen Eintrag (z.B. die IP-Adresse) in die Status-DB. Jeder andere Client, der jetzt auf diese Tabelle schreibend zugreifen will prueft, ob was in der Status-DB zur der Tabelle geschrieben ist, die er editieren will. Wenn ja erhaelt dieser Client nur Leserechte.
Das ganze wird dann bei AFTER POST und AFTER CANCEL wieder aus der Tabelle genommen.
Das einzige Problem bleibt, wenn der Client abstuerzt und nicht mehr in der Lage ist, die Tabelle freizugeben... Oder wenn der Server abschmiert...
Aber das kann man ja ueber ein Admin-Tool in jedem Client wieder loesen, welches dann einfach alle Blocks loescht...

Ich denke das waere die idealste Loesung fuer das Problem... Ausserdem betrifft es nur Tabellen und nicht gleich die ganze Datenbank...

Vielleicht faellt euch was besseres ein?

MfG Alex

Ich glaube ehrlich gesagt nicht, dass es Dir gelingen wird, Deine eigene "Überwachungsmethode" zu relisieren bzw. durchzuhalten.
Das Problem, dass mehrere Benutzer auf einer datenbank rumturnen und sich gegenseitig Ihre Veränderungen überschreiben ist auch nicht gerade neu, allerdings auch nicht sonderlich trivial.
Dein Problem liegt darin, dass Deine Anwendung einen Teilbereich, vielleicht auch die ganze Tabelle in den Arbeitsspeicher lädt und dann in irgendeiner Art in Deinem Programm darstellt und eventl nicht mitbekommt, dass diese Tabelle oder aber sogar der aktuell dargestellte Datensatz von einem anderen Benutzer im Netz verändert bzw. gelöscht worden ist.
Eine Lösungsmöglichkeit für mich würde darin bestehen, in dem BeforeEdit Event den aktuellen Datensatz zu aktualisieren und so die aktuellste Version darzustellen, dafür gibt es ja die Refresh-Möglichkeit, beim dbNavigator sogar den Refreh-Button.

Moin

Ja - und ich glaube genau das ist das Problem bei ADO + Access-DB. Die Datenbank wird komplett in den lokalen Arbeitsspeicher geladen. Das Programm soll aber fuer Mehrbenutzer ausgelegt werden. Ich werd jetzt mal schaun, ob es vielleicht trotzdem so funktioniert, wie ich mir das mit meiner eigenen Methode vorgestellt hab.
Also - die Eintraege in die Block-Tabelle werden schon richtig gesetze. Jetzt muss ich eben nur noch folgendes machen:

Bevor ein Client in den Edit-Mode uebergeht muss die Datenbank mittels Refresh aktualisiert werden. Dann muss geprueft werden, ob die Tabelle freigegeben ist, wenn ja wird sie geblockt fuer den aktuellen Clienten. Jetzt kann kein Client mehr schreibzugriff auf diese Tabelle erhalten. Nach dem Post wird der Eintrag wieder entfernt - was bereits funktioniert.
Aber zu eindeutigeren Ergebnissen wird man sicherlich nur durch Tests mit groesserer Client-Zahl kommen.

Aber dass muss ich erst noch testen.

Nur falls es jemenden interessiert - das System, welches ich mir ausgedacht hab funktioniert bis jetzt bestens! Tabellen werden gesperrt und anhand der IP-Adresse geblockt. Somit kann kein anderer den aktuellen Record veraendern.

Trotzdem baue ich zur Sicherheit eine Comando-Zeile mit ein, mit der man verschiedene DB-Optionen durchfuehren kann - unter anderem auch das Rucksetzen der Blockfelder.

Es ist zwar etwas Code-Arbeit - allerdings funktioniert es jetzt so, wie ich es haben will! Ist nicht ganz trivial, aber welcher Weg wuerde sonst offen bleiben?


Viele Gruesse

NetSpider

NetSpider hat folgendes geschrieben:

Nur falls es jemenden interessiert - das System, welches ich mir ausgedacht hab funktioniert bis jetzt bestens! Tabellen werden gesperrt und anhand der IP-Adresse geblockt. Somit kann kein anderer den aktuellen Record veraendern. Trotzdem baue ich zur Sicherheit eine Comando-Zeile mit ein, mit der man verschiedene DB-Optionen durchfuehren kann - unter anderem auch das Rucksetzen der Blockfelder. Es ist zwar etwas Code-Arbeit - allerdings funktioniert es jetzt so, wie ich es haben will! Ist nicht ganz trivial, aber welcher Weg wuerde sonst offen bleiben? Viele Gruesse NetSpider

Hallo, auch wenn man nicht in die Fusstapfen anderer treten will, muss man nicht alles neu erfinden. Datenbanken und Locking ist ein längst erforschtes Thema, für praktisches Arbeiten im professionellen Umfeld kommt eh nur Record Locking in Frage - Table Locking oder Data Base Locking machen die Anwendung für mehr als 2 bis 4 User praktisch unbrauchbar. Daher konnten schon die ältesten Datenbanken wie DBase Record Locking - allerdings geht das nicht einfach von selbst, man muss schon Programmierarbeit reinstecken. Z.B. weiss man ja oft nicht von vornherein, ob jemand nur was nachschaut, oder ob er was ändern will, meistens weiss er das selbst vorher nicht.

Dass das bei Access nicht so ohne weiteres geht und dass das niemand aufregt, liegt einfach daran, dass Access für den Multiuserbetrieb von vornherein ungeeignet ist. Es ist nur geeignet, um sich ein paar private Adressen und Geburtstage zu merken. Wer bisher versucht hat, Anwendungen für mehr als 5 Benutzer damit zu entwicklen, hat sich eine blutige Nase geholt, auch hochkompetente Entwicklungsabteilungen grosser Softwarehäuser haben spätestens nach einigen Jahren endloser Kundenreklanmationen das Handtuch geworfen und auf SQL-Server umgestellt.

Ausserdem skaliert Access nicht - ab einer bestimmten Dateigrösse, je nach Tabellenaufbau unterschiedlich, stürzt Access unweigerlich ab und vernichtet dabei den Datenbestand endgültig. Der Versuch eine Reparatur durchzuführen, bringt dann die MS-Typische Fehlermeldung: "MS Access kann diese Datenbank nicht reparieren. Dies liegt möglicherweise daran, dass sie beschädigt ist".

Also, dein Problem heisst Record Locking, und darüber gibt es ganze Bibliotheken voll Literatur.

Gruss Reinhard

Reinhard Kern hat folgendes geschrieben:

...auch hochkompetente Entwicklungsabteilungen grosser Softwarehäuser haben spätestens nach einigen Jahren endloser Kundenreklanmationen das Handtuch geworfen ...

Das widerspricht sich doch : Hochkompetente Entwicklungsabteilungen werden (eben wegen ihrer Kompetenz) niemals mit Access entwickeln. Aber ansonsten hast Du im Prinzip Rech

Ich würde auch einen SQL-Server (Firebird, PostgreSQL, MSSQL) nehmen. Record-Locking kann man direkt verwenden, oder man packt eine Mittelschicht rauf, die das Locking übernimmt.

Auf der anderen Seite gibt es natürlich noch andere Strategien, um dieses Problem zu lösen: Delphi bietet dafür eine ganze Reihe von Mechanismen an. Schau mal unter 'Reconcile' nach. Wenn Anwender 'A' die Adresse eines Kunden ändern will, und Anwender 'B' die Kontoinformationen, spricht doch nichts dagegen, beiden Anwendern den simultanen Zugriff auf den Datensatz zu erlauben.

Das Access ab einer bestimmten DB-Größe in die Knie geht, wusste ich noch nicht. Wo liegt diese Größe in etwa? Ein Kunde hat eine 800MB Datenbank und kommt relativ gut klar damit. Ok, er wartet morgens ne halbe Stunde, bis alle Daten geladen sind... Ich denke mal, Du meinst sowas wie 2GB (32 bit), oder?

Hallo,

Bei Access97 war die Grenze bei 1GB erreicht. Welche Version benutzt Du ?
Ausserdem wird record-level-locking sehr wohl von Access unterstützt. (ich glaube ab Version 2k)
Wird unter Options -> Advanced einfach per Haken aktiviert. Hatte damit bisher noch nie
Probleme bei ca 50 Clients. Probleme hatte ich früher nur bei Memo-Feldern.
Problem mit der kritischen Größe, Du kannst durch einen einfachen Maintenance-Plan die Access-DB jede nacht automatisch komprimieren.

Hi,

@espen:

Also ich bin mir jetzt nicht 100%ig sicher, aber ich glaube, dass die Optionen nur fuer das Programm Access zutreffen... Sobald ich eine Access-DB in ein Delphi-Programm einbinde sind die Optionen, die ich in Access vorgenommen hab dahin...
Ausserdem benoetigt der Rechner, auf dem die DB liegt keinerlei Treiber (wie beispielsweise die BDE)... Access muss also nicht installiert sein um mit dem Programm und der DB arbeiten zu koennen. Also wird auch kein Kontroll-Programm aktiv sein. Und die Datenbank wird sich wohl kaum alleine ueberwachen koennen.

Aber wie gesagt - ich bin mir da nicht so ganz sicher...

Viele Gruesse

NetSpider

espen hat folgendes geschrieben:

Ausserdem wird record-level-locking sehr wohl von Access unterstützt. (ich glaube ab Version 2k)Wird unter Options -> Advanced einfach per Haken aktiviert. Hatte damit bisher noch nie Probleme bei ca 50 Clients.

@espen, du scheinst ja viel erfahrung mit MS-access zu haben. eine frage, wenn ich einen daten satz mit select lese, um ihn später zu ändern, wie kann ich diesem beim select sperren, damit niemand anderer in der zwischenzeit den record ändert????

oracle, liefert mir hierfür das folgende konstrukt: select * for update..., nur wie gehts bei MS-access?

denke, das wäre auch die frage von NetSpider, nur mal anders ausgedrückt. <TIA>

Hallo,

@NetSpider:
Bei den Einstellungen der Access-DB hast Du natürlich recht. Aber deine Access-DB braucht selbstverständlich einen Treiber (MDAC) um per ADO angesprochen werden zu können. (Ich schreibe
hier ausschl. für den Zugriff per ADO)

@NetSpider und Grenzgaenger:
Um per ADO ein Record-Locking zu realisieren MUSS in der ADOConnection die CursorLocation auf
clUseServer eingestellt werden.
In der Query/Table ist es dann letztendlich egal, ob LockType auf ltOptimistic oder ltPessimistic gesetzt ist. (Ja, ich weiss da unterscheiden sich die Geister)

Siehe hier auch:
delphi.about.com/od/...base/l/aa061201b.htm

Aber Leute: Access ist keine Multiuser-DB. Punkt. Aus. Feierabend. Es geht nicht, das weiss auch Microsoft. Klar gibt es Anwendungen, wo es klappt. Meistens. Oder es sitzen nicht alle gleichzeitig dran. Bei einem Kunden hier (der mit den 800MB) gehen pro Tag ca. 2000 Aufträge rein, Die DB schmiert regelmäßig ab, Aufträge gehen verloren und die Rechnungen sind eben um einige Euronen kleiner. Das ist gut für deren Kunden, aber schlecht für unseren Kunden.

Deshalb eben: Raus aus Access, rein in eine echte DB. Access ist eine Tabellenverwaltung, aber keine Daten*bank* (Bank=Ort, wo das Zeugs *sicher* ist).

Natürlich kann man für <= 5 Anwender eine Access-DB mit den von espen vorgeschlagenen Lock-Mechanismen verwenden, aber eine Garantie, das die Daten sicher und unzerstörbar sind, gibt es so nicht.

alzaimar hat folgendes geschrieben:

Aber Leute: Access ist keine Multiuser-DB. Punkt. Aus. Feierabend.. ...

So isses.

Wir haben uns 3 Jahre mit einer Buchhaltung auf Accessbasis herumgeschlagen, die von einer renommierten Firma (Marktführer) erstellt wurde. Wegen der Probleme habe ich die Software wieder und wieder selbst analysiert, ich muss aber sagen, ich habe selten so saubere und professionelle Programmierarbeit gesehen - trotzdem stürzte Access bei Annäherung an etwa 90 MB Dateigrösse reproduzierbar und unreparierbar ab. Unreparierbar hiess, Datensicherung der Nacht zuvor zurückspielen, 3 Manntage im Eimer. Einzige Abhilfe: Daten löschen, um die DB wieder zu verkleinern.

Nach 3 Jahren wurde die ganze Accesslösung eingestampft und durch SQL ersetzt.

Meine eigenen Erfahrungen mit Access decken sich übrigens völlig damit, aber da könnte man ja sagen, ich wäre einfach zu blöd für Access. Wenn das so sein sollte, stehe ich jedenfalls nicht allein.

Gruss Reinhard