Multi-User Datenbank
-
- Beiträge: 138
- Registriert: 1. Mai 2006 19:50
Multi-User Datenbank
Hi,
mit QSqlQuery bzw. QSqlQueryModel lese dich Daten aus der Datenbank, in einen verctor ein. Diese Daten werden anschließend im Programm angezeigt, Änderungen werden in den vector geschrieben. Beim speichern der Daten wird der Inhalt des verctors wieder in die Datenbank geschrieben.
Wie kann ich die geöffneten Datensätze sperren, damit nicht der gleiche Datensatz von zwei Benutzern gleichzeitig bearbeitet werden kann?
Gruß
Whitefurrows
mit QSqlQuery bzw. QSqlQueryModel lese dich Daten aus der Datenbank, in einen verctor ein. Diese Daten werden anschließend im Programm angezeigt, Änderungen werden in den vector geschrieben. Beim speichern der Daten wird der Inhalt des verctors wieder in die Datenbank geschrieben.
Wie kann ich die geöffneten Datensätze sperren, damit nicht der gleiche Datensatz von zwei Benutzern gleichzeitig bearbeitet werden kann?
Gruß
Whitefurrows
-
- Beiträge: 138
- Registriert: 1. Mai 2006 19:50
Nein ich habe mich noch nicht mit Transaktionen beschäftigt. Das könnte aber die Lösung für mein Problem sein
Mir ist aber nicht ganz klar wie ich damit einzelne Datensätze zum löschen oder bearbeiten sperren kann. So wie ich das bis jetzt verstanden habe, kann ich mit transaction() die SQL-Anweisungen beginnen, waren diese erfolgreich, bestätige ich diese mit commit(), falls dies nicht erfolgreich war, können die zuvor ausgeführten Aktionen mit rollback() zurückgesetzt werden.
Ich müsste alle Datensätze die über die Select-SQL eingelesen werden für andere Benutzer zum löschen sperren, da diese dem Bearbeiter angezeigt werden und im vector enthalten sind. Wird ein Datensatz im Programm, bzw. im vector geändert, müsste dieser Datensatz für andere Anwender zusätzlich zum Bearbeiten gesperrt werden.
Kennst du zufällig ein kleines Beispiel, im dem etwas Derartiges veranschaulicht wird. Macht meine oben beschriebene Vorgehensweise überhaupt einen sinn oder sollte das Programm anders aufgebaut werden?
Mir ist aber nicht ganz klar wie ich damit einzelne Datensätze zum löschen oder bearbeiten sperren kann. So wie ich das bis jetzt verstanden habe, kann ich mit transaction() die SQL-Anweisungen beginnen, waren diese erfolgreich, bestätige ich diese mit commit(), falls dies nicht erfolgreich war, können die zuvor ausgeführten Aktionen mit rollback() zurückgesetzt werden.
Ich müsste alle Datensätze die über die Select-SQL eingelesen werden für andere Benutzer zum löschen sperren, da diese dem Bearbeiter angezeigt werden und im vector enthalten sind. Wird ein Datensatz im Programm, bzw. im vector geändert, müsste dieser Datensatz für andere Anwender zusätzlich zum Bearbeiten gesperrt werden.
Kennst du zufällig ein kleines Beispiel, im dem etwas Derartiges veranschaulicht wird. Macht meine oben beschriebene Vorgehensweise überhaupt einen sinn oder sollte das Programm anders aufgebaut werden?
-
- Beiträge: 138
- Registriert: 1. Mai 2006 19:50
Ja irgendwie schon, deshalb habe ich auch gefragt, wie man so ein Programm sinnvoll aufbauen kann, damit jeder Benutzer die richtigen Daten angezeigt bekommt. Deshalb wäre ich für weitere Tipps dankbar. Irgendwie müssen die Daten ja Temporär zur anzeige im Programm vorhanden sein, sprich in einem vector oder zumindest in einem Widget. Wie soll dann aber ein weiterer Benutzer die Änderungen angezeigt bekommen? Selbst wenn die Daten direkt gespeichert werden, das Programm müsste ja alle Datenbank zugriffe überwachen und die aktuellen Änderungen neu laden und anzeigen.
Unter Postgres gäbe es die Möglichkeit mit NOTIFY Änderungen zu überwachen, leider kann man dies mit der QtSql-Api nicht benutzen.
Dann gibt es noch die Möglichkeit im 10-Sekunden-Takt (1Min, 5Min, nach Bedarf) irgendwelche Timestamps abzufragen und bei Änderungen zu refreshen.
Oder die andere (verbreitetere) Möglichkeit: Der User entscheidet selbst wann er refreshen will und bekommt dazu einen Button.
Dann gibt es noch die Möglichkeit im 10-Sekunden-Takt (1Min, 5Min, nach Bedarf) irgendwelche Timestamps abzufragen und bei Änderungen zu refreshen.
Oder die andere (verbreitetere) Möglichkeit: Der User entscheidet selbst wann er refreshen will und bekommt dazu einen Button.
-
- Beiträge: 40
- Registriert: 4. Oktober 2004 16:26
Wen es interessiert: Hab hier schon mal was versucht. Für Postgres und Interbase/Firebird.
- Dateianhänge
-
- sqlNotifier.tar.gz
- (2.5 KiB) 178-mal heruntergeladen
Es kommt doch darauf an, was dein Programm ueberhaupt macht, wieviele User damit parallel arbeiten usw.Whitefurrows hat geschrieben:Ja irgendwie schon, deshalb habe ich auch gefragt, wie man so ein Programm sinnvoll aufbauen kann, damit jeder Benutzer die richtigen Daten angezeigt bekommt.
Eine Aktualisierung der Daten im Client ist in der Regel schon ab einigen Benutzern nicht mehr sinnvoll.
Erwartet der Benutzer eine automatische Aktualisierung?
Wie hoch ist die Wahrscheinlichkeit, dass verschiedene Benutzer gleiche Daten zur selben Zeit bearbeiten?
Goos