...
PgScript ist böse, denn es teilt an den ; den Text auf und sendet alles als einzelne Abfragen zur
DB.
(macht Spaß, wenn das Aufteilen nicht an den richtigen Stellen schneidet)
...
Danke schonmal für den Hinweis! Das hätte ich tatsächlich als nächstes versucht,
aber dann brauche ich das damit gar nicht erst versuchen.
...
Beim PgQuery kann man einstellen was es macht, womit sich da auch de-/aktivieren lässt, dass mehrere Befehle gehen (kann auch sein, dass eine Option an der Connection war)
Ich denke mal sowas hast bei dir umgestellt oder vergessen zu machen.
...
Zumindest finde ich diese Einstellung nicht.
...
Statt BEGIN und COMMIT kannst du aber bestimmt auch die Transaktion über die Connection-Klasse starten, bzw. mit einem Transactionsmanager an der Connection.
Ich will keine in sich geschlossene Transaktion starten.
Daher wunderte es mich, dass "BEGIN ... COMMIT;"
sich (im pgAdmin) auftrennen lässt auf zwei nacheinander ausgeführte Querys.
Aber es macht genau das, was ich brauche.
Hallo,
Lock auf
DB-Ebene ist auf jeden Fall keine gute Idee.
...
Kannst du das begründen?
Das dort gezeigte Beispiel verwendet mehrere Befehle (was ja bei mir nicht geht) und außerdem
wird das als Beispiel für einen Vorgang genommen, welcher "in einem Rutsch" durchgeführt wird.
Ich würde mal in Frage stellen, ob so eine Workflow Aktion (Reservierung) über solche Mechnismen sinnvoll ist.
M.E. ist das ein Bestellstatus ("ImWarenKorb"), der den Artikel aus dem Lager entfernt.
...
Dann habe ich das vielleicht nicht gut genug erklärt.
Stellen wir uns vor, wir hätten einen Kassiervorgang bei dem nun ein Arikel hinzugefügt werden soll.
Hier bietet sich wunderbar eine Transaktion an:
- Position hinzufügen
- Ware aus dem Bestand/Lager entfernen
- meinetwegen noch in den Kopfdaten die Summenwerte anpassen (ist zwar doppelte Datenführung wird aber gerne gemacht, auch als Kontrolle für konsistente Daten)
Das alles passiert in einem Rutsch. Nur in mehreren Tabellen.
Also sehe ich hier eine ideale Verwendung für Transactions.
Zumindest habe ich so Transaktionen bisher mit solchen Aktionen in Verbindung gebracht.
Da wäre ich tatsächlich bei dir:
- Eine seperate (evtl. neue?) Connection
- Transaction Start
- Alle Querys nacheinander so wie man das gerade braucht und/oder möchte
- Transaction Ende
Wunderbar. Dann wäre es auch völlig egal, dass ich pro
Query.ExecSQL(); nur einen Befehl abschicken kann.
Jetzt will ich aber sowas gar nicht.
Ich will eher sowas wie das Bearbeiten eines Kunden im Kundenstamm.
Ich habe unzälige Mitarbeiter in der Firma.
Einer öffnet den Kundenstamm und will diesen bearbeiten.
Beim Bearbeiten muss dieser eine Datensatz im Kundenstamm gegen das Bearbeiten
durch andere Mitarbeiter gesperrt sein. Sicher kann man noch einbauen,
dass wenn der Mitarbeiter Kaffee holen geht und die Maus 10 Minuten nicht bewegt wird,
dass das Bearbeiten dann abgebrochen wird oder was auch immer man lustiges machen möchte.
Ich brauche aber dafür halt einen Mechanismus der sicherstellt,
dass der Datensatz für andere zum Bearbeiten gesperrt ist.
Ich hoffe du erkennst an dem Beispiel besser was ich will.
Du hängst mit dem Warenkorb-Beispiel tatsächlich eher bei einer Transaction (1 Event)
und weniger bei einem Lock (2 zeitlich unabhängige Events).
(Auch wenn innerhalb der Transaction ja schon der
SQL-Befehl für "Lock" benutzt wird.)
Hier vielleicht noch angemerkt, dass ich keinen Anspruch darauf erhebe, dass ich
die Wörter "Lock" und "Transaction" tatsächlich richtig versetehe, aber so sollen
sie zumindest in meinen Posts gedacht sein und so passt es meines Erachtens nach auch
am Ehesten zu den Beschreibungen, welche ich bisher so gelesen habe.
...
Ansonsten:
Die
Query Komponenten, die ich kenne machen automatisches Transaktionshandling und sind nicht fähig, mehrere Befehle zu verarbeiten.
Man kann in PG wie in Deinem Beispiel anonyme Blöcke nutzen, aber (natürlich) auch nicht in 2 separaten Queries.
...
In pgAdmin kann ich (wie oben schon erwähnt) tatsächlich das "BEGIN" und das "COMMIT" in zwei zeitlich unabhänige
Query schreiben. Das funktioniert und macht genau das, was es soll.
---
Unterm Strich: Wie löst ihr das Sperren von Stammdaten zum Bearbeiten?
Oder habt ihr andere Komponenten, bei denen das so funktioniert wie es auch in pgAdmin selbst funktioniert?
Stört ihr euch vielleicht gar nicht daran, wenn Anwender einen Datensatz
von zwei Stationen bearbeiten können?
Bei ADS (Advantage Datebase Server) sperrt die Table-Komponente den Datensatz,
wenn man "TheTable.Edit();" verwendet (bis zum TheTable.Post()
.
Ich meine bei
MySQL/MyDac genau so.
Wenn ich also raten soll, würde die UnitTable das auch machen.
Also werde ich wohl mal darüber versuchen was zu bauen, erscheint mir aber irgendwie falsch/affig.
Liebe Grüße und Danke schonmal für die Zeit und Hilfe bis hierher
Incocnito