Multiuser mit C-API

[AMaurer]

Hier also Frage 2 zu meiner Anwendung - Auftragsverwaltung

Ich benutze keine Komponenten sondern C-API für den Zugriff auf die MySQL-Datenbank. Die Daten, die im Formular angezeigt sind also nicht datensenstiv, sondern nur in dem Moment der Abfrage aktuell.

Wie schaffe ich es, dass beim Multi-User-Zugriff (ca. 8 Anwender) kein Datensalat entsteht.

Gibt es hierzu ein paar praktische Tipps?

Soll ich in der Tabelle/den Tabellen ein Feld "gesperrt" anlegen und den jeweils im Formular angezeigten Datensatz in der DB-Tabelle als gesperrt markieren? Oder erst bei einem Feld-Edit?

Vielleicht gibt es von Michael Puff das Fortgeschrittenen-Tutorial, das auf das Anfänger-Tutorial aufbaut???

Alle Beispiele, die ich gefunden habe behandeln dieses Problem nicht.

Danke für Eure Hilfe.

Andreas

[mkinzler]

Der lowlevel Ansatz macht vielleicht Sinn, wenn man eine Delphiversion ohne Datenbankunterstützung verwendet. Da du aber ein pro Version mit datenbankunterstützung verwendest würde ich diese auch verwenden!

[AMaurer]

Hallo Markus,

danke für die schnelle Antwort.

Ich hatte auch einen Ansatz mit ZEOs, bin allerdings wieder davon weg, da mir das zu unübersichtlich wurde. Die Anwendung läuft in einem Formular, indem entsprechend der Auswahl im Menü Panels ein- bzw. ausgeblendet werden. Insgesamt ca 30 Tabellen lassen sich so pflegen. Dazu die ganzen DataSources, DataSets usw.

Außerdem sind die "ZEOs-Daten" in den Formularen doch dann auch nicht datensensitiv, oder? Es hat ja auch Vorteile, wenn dem nicht so ist. Dann wird ein Feld-Edit nicht gleich in die DB geschrieben sondern man kann die Aktion separat auslösen.

Wie wird der konsistente Multi-User-Zugriff denn hier gelöst?

Andreas

[himitsu]

Zum Ansprechen eines MySQL-Servers machen sich fertige Komponenten bestimmt nicht schlecht.

Ansonsten läßt sich die LibMySQL.dll direkt ansprechen, aber die ist natürlich nur eine Single-App-Schnittstelle. (man kann die API in einer eigenen DLL/EXE kapseln und dann über threadsichere Aufufe von mehreren Stellen und via IPC auch von mehreren Programmen aus aufrufen)
LibMySQL ...
LibMySQL Header

[mkinzler]

Zitat:

Außerdem sind die "ZEOs-Daten" in den Formularen doch dann auch nicht datensensitiv, oder? Es hat ja auch Vorteile, wenn dem nicht so ist. Dann wird ein Feld-Edit nicht gleich in die DB geschrieben sondern man kann die Aktion separat auslösen.

Man kann datensensitive Komponenten verwenden muss es aber nicht.

Zitat:

Wie wird der konsistente Multi-User-Zugriff denn hier gelöst?

Es gibt verschiedene Ansätze dafür, unabhängig vom Zugriffsweg:
-Sperrtabellen
-verfügbare Sperrfunktionalität der verwendeten storage-engine
-Events

[conrad]

Man muss Datensätze nicht zwingend sperren, um Datensalat zu vermeiden.

Die typische vorgehensweise ist ja in der Regel die folgende:

1. Benutzer erhält Datensatz zur Anzeige (1 Sekunde)
2. Benutzer führt Änderungen durch (3 Minuten)
3. Benutzer speichert Daten (1 Sekunde)

Für Schritt zwei wird üblicherweise die meiste Zeit benötigt - nämlich genau so viel, wie der Benutzer benötigt, um sich Daten auszudenken und einzugeben. Probleme treten auf, wenn während Schritt zwei in der Datenbank Änderungen vonstatten gehen.

Doch statt diese Veränderungen zu verhindern, könnte man versuchen, mit ihnen umzugehen. Benutzer führen Änderungen in der Regel nicht vor lauter Langeweile, sondern weil etwas wichtige ansteht, durch. Vor einem gesperrten Datensatz zu stehen resultiert in Frust.

Eine Möglichkeit ist, während Schritt eins den Zustand des Datensatzes beiseite zu legen. Anschließend lässt man den Benutzer seine Eingaben machen. Im dritten Schritt vergleicht man, vor dem Speichern, den aktuellen Zustand des Datensatzes wie er aktuell in der Datenbank liegt, mit dem Abbild im Zwischenspeicher aus Schritt eins. Falls zwischen den beiden ein Unterschied besteht, wurde in der Zwischenzeit von einem weiteren Benutzer eine Änderung vorgenommen.

Den Vergleich kann man auch mit Hilfe eines Zeitstempels, Hashs oder eines x-beliebigen, zufälligen Codes, welcher bei jeder Veränderung am Datensatz gespeichert wird, vornehmen.

An dieser Stelle gibt es nun vielfältigste Möglichkeiten der Behandlung:

A) Den vom Benutzer bearbeiteten Datensatz verwerfen und den neuen Stand aus der Datenbank erneut zur Bearbeitung vorlegen.
B) Den Benutzer nach dem weiteren Vorgehen befragen: Verwerfen oder Überschreiben?
C) Eine komfortable Oberfläche zur Zusammenführung der beiden Stände bereitstellen.

In der Regel wird nicht ein Benutzer einen Auftrag freigeben, während ein anderer ihn storniert. Ich behaupte mal, es sind meist Änderungen, die problemlos gemeinsam existieren und somit durch ein intelligentes System zusammengeführt werden können.

[AMaurer]

Das ist doch mal eine pragmatische Antwort. Danke!

Wenn Du jetzt noch einen Tipp für meinen Thread "Report und C-API" hast ... Das ist eher zum Verzweifeln.

Viele Grüße

Andreas

[Sir Rufo]

Also bei einem Multi-User-Zugriff sollte man sich so Sachen abschminken wie:

- das machen die doch nicht
- das ergäbe doch keinen Sinn

Denn das machen die doch, auch wenn es keinen Sinn ergibt. Ich glaube zwar, das da keine böse Ansicht zu Grunde liegt, sondern einfach eine andere Fokussierung.

Somit ist es doch kein Problem einen Hinweis anzuzeigen, dass der DS gesperrt ist durch Benutzer xy.
Wenn es notwendig ist, dann kann man ja eine Übertragung der Sperre implementieren.

Bei einer Auftragsverwaltung macht es auch Sinn, die Daten zu einem neuen Auftrag schon direkt in der Datenbank zu speichern (z.B. um die ausgewählten Artikel schon mal zu reservieren, sonst verkauft Verkäufer B die parallel an einen anderen Kunden und Verkäufer A kommt in Erklärungsnot)

Wenn da ohne Sperre gearbeitet wird, und der Auftrag mal eben freigegeben wird ...