Mehrbenutzerzugriff und die Lösung von Konflikten?

[Stephan Schneider]

Hallo,

Umg.: Delphi 6 Ent. UP2, BDE 5.2, Paradox

Woher erhalte ich Infos über die Handhabung von Mehrbenutzerzugriffen und daraus resultierenden Konflikten (inkl. Lösungen) bei zugrundeliegender BDE als DB-Engine?

Stephan

[Jochen Reichenberg]

Hallo Stephan,

ist im Prinzip recht einfach. Das A und O dabei ist, daß das NetFileDir auf allen Rechnern auf das gleiche Verzeichnis zeigen muß. Ansonsten führst Du Manipulationen an der DB in try catch (EDBEngineError &ErrObject) und wertest den Fehler im ErrObject aus.

ABER:<BR>
Ist das ein neues Projekt? Wenn ja, solltest Du dich nach Alternativen zur BDE umsehen (z.B. Firebird). Die BDE ist nicht mehr für aktuelle Betriebssysteme geeignet. Es gibt dort eine Menge Fallstricke, auf die man nur schwer oder gar nicht reagieren kann. Außerdem ist die BDE im Netzwerk sehr langsam.

Grüße Joche

[Stephan Schneider]

Hallo Jochen,

das Projekt ist schon sehr betagt, etliche Jahre alt. Die BDE war damals das Mittel der Wahl.

Das NetFileDir muss für alle Clients auf das gleiche Verzeichnis verweisen, dies ist klar.

Ich meinte eher Konfliktsituationen, wie sie im Mehrbenutzerbetrieb allgemein vorhanden sind:

Benutzer A arbeitet an etwas, wobei mehrere Tabellen (z.B. über eine TQuery handelbar) betroffen sind. Benutzer B arbeitet ebenfalls im gleichen Bereich, nur etwas später. Die Änderungen, die A gemacht hat, wären somit obsolet. Nun möchte ich sicherstellen, wenn Benutzer A arbeitet, dass kein anderer Benutzer ebenfalls daran arbeiten kann.

- Müssen alle betroffenen Tabellen exklusiv geöffnet werden?
- Wie sähe dies im Falle bei der Verwendung einer TQuery aus?

Welche gängigen Prinzipien gibt es hier in Zusammenhang mit der BDE?

Herr Kosch hat sich in seinem Buch <i>ADO und Delphi</i> Mehrbenutzerkonflikten angenommen, nur eben vor dem Hintergrund ADO, und nicht der BDE.

Stepha

[Jochen Reichenberg]

Hallo Stephan,

wie gesagt mache ich das über try catch, respektive try, __except, __finally (ich hoffe mal, das gibt's überhaupt in Delphi...). Beispiele könnte ich nur in C++ geben (Borland C++ Builder, ist aber in großen Bereichen mit Delphi identisch).

Da ich selten TDataBase-Komponenten (dort siehe Eigenschaft TransIsolatíon) verwende, sondern lieber TQuery + TUpdateSQL verwende, gehe ich somit den 'harten' Weg, indem ich die Daten in normale Edits einlese, den Benutzer die Daten ändern läßt und vor dem zurückschreiben prüfe, ob die Daten zwischenzeitlich geändert wurden (dazu muß man sich die alten Werte natürlich merken). Dies hat aber den enormen Vorteil, daß Datensätze nur kurzfristig gesperrt sind. In der Praxis habe ich dabei bisher noch keinen Fall erlebt bei denen zwei Clients gleichzeitig versucht haben, einen Datensatz zu modifizieren (in 3 Jahren, bei mittlerweile 35 Clients). Und da ich meinen Kollegen irgendwie nicht vermitteln kann nicht in die Pause oder auf das Stille Örtchen gehen, während sie einen Datensatz bearbeiten...

Grüße Joche