Datensatzsperre und refresh in MySql-Datenbank

[steirer]

Hallo,
ich habe (als MySql-Neuling/ mySql 4.1 am localhost , ZEOS-Komponenten 6.1) folgendes Problem:

Ich habe mehrere DBedits mit einem TQuery verbunden (select * from artikel; requestlive:true).
Für die Verbindung zur Datenbank (InnoDB) sind die Einstellungen:
Autocommit: true;
Transactisolation: tiRepeatableRead;
Die Navigation erfolgt mit DBNavigator.


1. Problem:
Offenbar wird die gesamte Tabelle in den Arbeitsspeicher geladen.

2.Problem (hängt offenbar mit dem ersten zusammen):

Wenn ich Änderungen im Datensatz vornehme, wird der Datensatz offenbar nicht gesperrt (ich habe testweise die gleiche Anwendung noch mal gestartet und kann den gleichen Datensatz in beiden Anwendungen gleichzeitig verändern, ohne einen Hinweis zu erhalten).

Externe Änderungen in der Tabelle werden beim normalen blättern in der Tabelle nicht erkannt, sondern erst nach neuerlichem ZQuery.open bzw. explizitem ZQuery.refresh.

Benötigen würde ich:
Datensatz für Datensatz wird aufgerufen und nicht die ganze Tabelle auf einmal
Datensatz wird bei Änderung gesperrt und nach post wieder freigegeben.

Danke für eure Hilfe!

[Bernhard Geyer]

Zitat:

Zitat von steirer

1. Problem:
Offenbar wird die gesamte Tabelle in den Arbeitsspeicher geladen.

MySQL unterstützt keine Serverseitigen Curser. D.h. das gesamte Ergebniss einer Abfrage muss zum Client übertragen werden.

Zitat:

Zitat von steirer

2.Problem (hängt offenbar mit dem ersten zusammen):
Wenn ich Änderungen im Datensatz vornehme, wird der Datensatz offenbar nicht gesperrt (ich habe testweise die gleiche Anwendung noch mal gestartet und kann den gleichen Datensatz in beiden Anwendungen gleichzeitig verändern, ohne einen Hinweis zu erhalten).

Dazu mußt Du den Tabellentyp InnoDB verwenden. Erst mit Version 4.0 ist dieser Typ in der Standardauslieferung von MySQL dabei.
Der Standard-Tabellentyp unterstützt keine Transaktionen (und damit Sperrung).

Zitat:

Zitat von steirer

Externe Änderungen in der Tabelle werden beim normalen blättern in der Tabelle nicht erkannt, sondern erst nach neuerlichem ZQuery.open bzw. explizitem ZQuery.refresh.

Ist bei SQL-Datenbanken normal. Erst wenn die Datenmenge aktualisiert wird (Close/Open, Refresh, Resync) werden zwischenzeitliche Änderungen anderer erkannt und angezeigt.

[steirer]

:pale: Danke für deine Antworten, damit scheint mir MySql für eine Client-Server-Anwendung (Auftragsbearbeitung) mit mehreren Usern gleichzeitig nicht wirklich geeignet. Gibts eine Alternative mit serverseitigem Cursor, möglichst frei einsetzbar und auf Linux lauffähig. Würde FB das alles erfüllen?
Peter

[Jelly]

Zitat:

Zitat von steirer

Würde FB das alles erfüllen?

Definitiv, JA. FB ist viel besser geeignet als MySQL.

[Bernhard Geyer]

Zitat:

Zitat von steirer

:pale: Danke für deine Antworten, damit scheint mir MySql für eine Client-Server-Anwendung (Auftragsbearbeitung) mit mehreren Usern gleichzeitig nicht wirklich geeignet. Gibts eine Alternative mit serverseitigem Cursor, möglichst frei einsetzbar und auf Linux lauffähig. Würde FB das alles erfüllen?
Peter

Wieso? Verwende InnoDB-Tabellen, so ist das Problem mit den Transaktionen gelößt. Und Serverseitige Curser sollten im CS-Umfeld eh vermieten verwenden, da sie serverseitig eine hohe Last erzeugen, da ja u.U. die gesamte Datenmenge auf dem Server als Kopie (wird so bei MS-SQL-Server gemacht, welcher das Multi-Versions-Konzept nicht unterstützt) erzeugt werden muss und währen der kompletten Transaktion (wenn die Queryverbindung offen ist) vorgehalten muss. Un nun stell dir mal die Serverlast vor, wenn 100 User eine Tabelle mit 1 Mio. Datensätzen und jeder Datensatz 1 kByte Speicher verbraucht.

Im CS-Umfeld sind ein paar entscheidungen zu Desktopdatenbanken unterschiedlich zu treffen:
- Möglichst kleine Ergebnismengen produzieren
- Transaktionen kurz halten
- Wenn möglich keine Serverseitigen Curser verwenden

Wir selbst setzen MySQL erfolgreich als CS-Datenbank ein (neben MS-SQL und Oracle).

[DennisHB]

Ich bin mir nicht ganz sicher wie es mit Delphi ist aber per PHP kann man die Ausgabe auf Anfragen zb "select" mit zB. "limit 30" begrenzen.

[steirer]

Also doch MySQL? Wie gesagt, bin ich ein Newby was MySQL betrifft (und auch echte Client-Server-DB-Anwendungen). :oops: Daher schäme ich mich auch nicht zu fragen, wie ihr den Spagat zwischen "kleiner Datenmenge zurückgeben" und "komfortablem Blättern" (natürlich mit aktuellen Daten) löst.

Für alle Antworten dankbar!

[Bernhard Geyer]

Zitat:

Zitat von DennisHB

Ich bin mir nicht ganz sicher wie es mit Delphi ist aber per PHP kann man die Ausgabe auf Anfragen zb "select" mit zB. "limit 30" begrenzen.

Damit wird aber nicht das Problem das Server-/Clientseitigen Cursers gelößt, sondern "nur" die Ergebnissmenge fest auf eine Maximalanzahl ergebnisdatensätze beschränkt (ist für manche Suchfunktion sinnvoll). Will man nun weitere Ergebnisse, so muss mann mittels angepaßter Limit-Angaben neue Abfragen stellen.

[steirer]

Ich habe vorerst Folgendes vorgenommen, um online Veränderungen in der DB mitzubekommen (schlagt mich nicht, mir ist bewusst, dass das nicht performance-optimierend ist):
als onklick-Ereignis auf den DB-Navigator führe ich einen refresh auf das TQuery durch (komplett reingeladen ca 10.000 Records) und setze die Tabelle auf Edit wenn sie vor dem Klick Status dbInsert oder dbEdit hatte.

Das ist aber eine totale "Pfui"-Lösung (schäm,schäm) ich weiß aber nicht, wie ich's besser machen könnte (Blättern/suchen in der Artikel-Tabelle mit aktuellen Daten).

Danke für eure Ratschläge!

[barnti]

Hallo,

wie Bernhard schon bemerkte: Lade die Daten, die benötigt werden. Für das Sperren auf Datensatzebene benutze InnoDB-Tabellen. Um einen Datensatz zu sperren kannst Du dann den betreffenden Record mit:

SQL-Code:

SELECT DasUndDas,DiesAuch
FROM MeineTabelle
WHERE MeineTabelle_ID= BenötigteBedingung
FOR UPDATE

für andere Benutzer sperren.
Mit dem 'FOR UPDATE'-Statement werden dann alle durch das SELECT gelesene Datensätze für den schreibenden Zugriff gesperrt.
Ich kann Dir empfehlen erst mal zwei mysql-Verbindungen in zwei Shells zu öffnen. Dann kannst Du mit den Statements zum Sperren experimentieren.
Sehr hilfreich ist das zugehörige Manual