Hallo DP,

die grobe Aufgabenbeschreibung lautet so:
ich soll die mehrmalige Bearbeitung eines Datensatzes über mehrere Standorte hinweg verhindern, das Lesen des Datensatzes soll dabei aber noch möglich sein.

Die Rahmenbedingungen dazu sind: wir haben drei Standorte, die über Standleitungen miteinander Kommunizieren. In allen drei Standorten gibt es einen Datenbank-Server mit Advantage Database Server (8.1) mit den entsprechenden Datenbanken. An allen drei Standorten sind die Daten aller Standorte vorhanden (wird durch die Replikation des Datenbank-Servers sichergestellt).

Nun ist es ja theoretisch möglich, dass an Standort A und B der Datensatz X geöffnet und bearbeitet wird. Dieses soll ich nun verhindern, stellt sich nur die Frage wie?

Der erste Ansatz wäre ein zusätzliches Datenbank-Feld, das true ist, wenn der Datensatz an irgendeinem Standort geöffnet wird und beim Verlassen wieder auf false gesetzt wird. Hat aber eine Menge Probleme und Nachteile, hat irgendwer andere Vorschläge?

Zitat:

Der erste Ansatz wäre ein zusätzliches Datenbank-Feld, das true ist, wenn der Datensatz an irgendeinem Standort geöffnet wird und beim Verlassen wieder auf false gesetzt wird.

Die Frage wäre hierbei nur, ob die Replikation schnell genug ist, um so eine mehrfache Bearbeitung zu verhindern.

Zitat von mkinzler:

Die Frage wäre hierbei nur, ob die Replikation schnell genug ist, um so eine mehrfache Bearbeitung zu verhindern.

Genau das war auch mein erster Gedanke. Hier müsste man wahrscheinlich direkter über Trigger gehen.

Zitat:

Die Rahmenbedingungen dazu sind: wir haben drei Standorte, die über Standleitungen miteinander Kommunizieren. In allen drei Standorten gibt es einen Datenbank-Server mit Advantage Database Server (8.1) mit den entsprechenden Datenbanken. An allen drei Standorten sind die Daten aller Standorte vorhanden (wird durch die Replikation des Datenbank-Servers sichergestellt).

Hallo

wieso sind die Datenbanken 3-fach vorhanden, wenn die Standorte sowieso über Standleitungen verbunden sind ?

Lösung: nur 1 Datenbankserver, die 2 anderen Standorte greifen remote z.B. über Terminal-Sessions drauf zu.


Viele Grüsse

Zitat von mkinzler:

Zitat:

Der erste Ansatz wäre ein zusätzliches Datenbank-Feld, das true ist, wenn der Datensatz an irgendeinem Standort geöffnet wird und beim Verlassen wieder auf false gesetzt wird.

Die Frage wäre hierbei nur, ob die Replikation schnell genug ist, um so eine mehrfache Bearbeitung zu verhindern.

Trigger über mehrere Standorte? Wie würde sowas gehen?

Zitat von ManuelR:

Hallo

Wieso sind die Datenbanken 3-fach vorhanden, wenn die Standorte sowieso über Standleitungen verbunden sind ?

Lösung: nur 1 Datenbankserver, die 2 anderen Standorte greifen remote z.B. über Terminal-Sessions drauf zu.


Viele Grüsse

Weil die Standleitungen öfters mal weg sind und in einem solchen Fall in den einzelnen Werken kein weiteres Arbeiten mehr möglich wäre.
I.d.R. sollte das Bearbeiten von zweimal desselben Datensatzes nicht auftreten, aber es kann eben auch nicht ausgeschlossen werden => Forderung der extrem hohen Sicherheit

Ich persönlich vermute eigentlich, dass das Problem nie auftreten wird (weil jeder Sachbearbeiter eben seine eigenen Daten bearbeitet) aber mein Chef sieht das etwas anders

Zitat von ManuelR:

wieso sind die Datenbanken 3-fach vorhanden, wenn die Standorte sowieso über Standleitungen verbunden sind ?

Wahrscheinlich wegen Geschwindigkeit und Ausfallsicherheit. Und hier haben wir dann gleich ein Problem: Wenn die Daten editierbar sein sollen, auch wenn die Standleitung ausfällt, so dürfen die anderen Rechner nicht eine Zwangssperrung bekommen, weil sonst das ganze System steht!
Ich würde das mehrfache Editieren zulassen und über Konflikttrigger die Business Rules realisieren (zB einen Zeitstempel mitführen, der neueste Datensatz gewinnt...oder im Konfliktfall die entsprechenden Datensätze mitloggen und zur wiederbearbeitung vorlegen..oder, oder, oder).

Zitat von joachimd:

Zitat von ManuelR:

wieso sind die Datenbanken 3-fach vorhanden, wenn die Standorte sowieso über Standleitungen verbunden sind ?

Wahrscheinlich wegen Geschwindigkeit und Ausfallsicherheit. Und hier haben wir dann gleich ein Problem: Wenn die Daten editierbar sein sollen, auch wenn die Standleitung ausfällt, so dürfen die anderen Rechner nicht eine Zwangssperrung bekommen, weil sonst das ganze System steht!
Ich würde das mehrfache Editieren zulassen und über Konflikttrigger die Business Rules realisieren (zB einen Zeitstempel mitführen, der neueste Datensatz gewinnt...oder im Konfliktfall die entsprechenden Datensätze mitloggen und zur wiederbearbeitung vorlegen..oder, oder, oder).

Die Konflikttrigger werden zusätzlich benötigt. Das Problem liegt aber eher weniger an dem Dateninhalt, sondern was mit dem Datensatz u.U. passieren kann: Der Datensatz könnte z.B. ein Angebot (bzw. Auftrag) sein, das abgegeben werden soll: Mitarbeiter A geht in Druckvorschau und bevor er das Angebot ausdruckt oder per Email verschickt, geht er erst einmal zu Mittag.
In der Zwischenzeit kümmert sich der Mitarbeiter B um das Angebot (z.B. weil der Kunde anruft und drängelt) und ändert was daran, druckt es aus und verschickt es.
Nach dem Mittag kommt A wieder, druckt Angebot aus und verschickt es. Folge: der Kunde erhält zwei Angebote mit gleicher Nummer und Änderungsindex und weiss nicht mehr was das soll.

Wie gesagt: ich halte dieses Scenario für relativ unwahrscheinlich, aber mein Chef will das eben so

Du kannst das szenario auch so ändern, das alle auf der zentralen DB arbeiten, welche an den Standorten repliziert wird. der Client überprüft dann beim Start ob zentrale Db erreichbar sonst Rückfall auf replizierte DB

Zitat von mkinzler:

Du kannst das szenario auch so ändern, das alle auf der zentralen DB arbeiten, welche an den Standorten repliziert wird. der Client überprüft dann beim Start ob zentrale Db erreichbar sonst Rückfall auf replizierte DB

Dagegen spricht die Geschwindigkeit der Standleitungen (eine ist zur Zeit nur 128K schnell, versuchen die gerade auf 2MBit hochzurüsten, ob das aber klappt weiss noch nicht mal die T-Kom).

Für eine SQL-Datenbankverbindung sollte das eigentlich reichen.