automatische Transaktionen

[Joh]

Moin,

Code: Alles auswählen

System:
Lazarus 2.2.4 unter Windows 10
Firebird 4.01
SQLDB

Von früher kenne ich das Arbeiten mit Transaktionen so:
- Klick auf Datensatz bearbeiten // oder so
- Transaktion starten
- Datensatz bearbeiten
- Transaktion beenden mit Commit / Rollback.

Hier wird ja mit automatischen Transaktionen gearbeitet. D.h., wenn ich in einem anderen Fenster (mit eigener Datenumgebung) oder in einer anderen Anwendung Daten ändere, bekomme ich dieses ja aktuell gar nicht mit.
In meinem Fall ein Artikel mit subArtikeln, wobei ich trotz

Code: Alles auswählen

    subArtikel.Close;
    subArtikel.ParamByName(id').AsInteger := SQLArtikel.FieldByName('id').AsInteger;
    subArtikel.Open;

auf die durch andere Transaktionen (Fenster) in der DB gespeicherte Daten keinen Zugriff habe.
Ich weiß, Close und Open beenden nicht die Transaktion...

Klar kann ich jetzt beim Datensatzwechsel die Transaktion beenden und neu starten, aber das kann ja nicht Sinn der Sache sein.

Wo liegt gerade mein Denkfehler?

[af0815]

Vielleicht der erste Fehler - man kann mit automatischen Transaktionen arbeiten, muss es aber nicht - die Automatik funktioniert in bestimmten Bereichen nicht (it's by design - Copyrigth by MvC), gerade wenn du mit Stored Procedures (unlogischerweise) arbeitest.

Es macht auch Sinn in einer Mehrbenutzerumgebung die Tabellen rasch wieder freizugeben (bzw. die Datensätze, je nach DB). Deswegen ist das mit den manuellen Transaktionen nicht so abwegig.

Ein Close einer Query ist aber schon ein Zeitpunkt, wo Änderungen in der DB normalerweise spätesten festgeschrieben werden.

Zu deiner Frage, wenn sich der Datensatz der Haupttabelle ändert, musst du mit der verbunden Tabelle was machen. Wenn dort ein Datensatz geändert, eingefügt oder gelöscht wurde, musst du spätestens jetzt eine Entscheidung treffen - Commit und aktzeptieren oder Rolback und die Änderungen verwerfen. Du hast nur eine Query die für eine Abfrage (Tabelle, View) steht. Da hat kein Fenster was damit zu tun, sondern nur die zuständige Query. Ob die jetzt in einem anderen Fenster liegt oder Datenmodul ist komplett egal, du musst die Logik ja wo unterbringen und dir den entsprechen Zugriffsweg schaffen. Das hast du ja, sonst könnte kein Benutzer mit den Daten was machen.

Wie gesagt, die Logik aus früheren Zeiten hat weiterhin Bestand .

[Joh]

In Fenster2 (subArtikel) mache ich ja ein Commit / bzw. Commitretaining.
Die Daten kommen auch in der DB an. Alles Gut. Externe Tools wie DBeaver zeigen sie mir an.

Nur mein Artikelfenster halt erst nach dem Beenden der Transaktion.

Edit:
Wo stelle ich denn ein, das ich Transaktionen manuell ausführen möchte? Aktuell zeigt mir kein Fenster Daten an ohne aktive Transaktion.
funktioniert scheinbar ja doch; ich melde mich dazu...

[Joh]

nee, funktioniert erstmal nicht.

Sobald ich eine Query aktiv setze, wird die Transaktion automatisch gestartet.

Bei Transaction.Options = [stoExplicitStart] kommt die Meldung "attempt to implicitly start a transaction on Connection..."

[Joh]

Es macht auch Sinn in einer Mehrbenutzerumgebung die Tabellen rasch wieder freizugeben (bzw. die Datensätze, je nach DB). Deswegen ist das mit den manuellen Transaktionen nicht so abwegig.

Ist mir klar; das mit den automatischen Transaktionen finde ich von daher eher gruselig.

Zu deiner Frage, wenn sich der Datensatz der Haupttabelle ändert, musst du mit der verbunden Tabelle was machen. Wenn dort ein Datensatz geändert, eingefügt oder gelöscht wurde, musst du spätestens jetzt eine Entscheidung treffen - Commit und aktzeptieren oder Rolback und die Änderungen verwerfen. Du hast nur eine Query die für eine Abfrage (Tabelle, View) steht.

Mit automatischen Transaktionen bedeutet jetzt erstmal: Bei jedem Datensatzwechsel der Hauptdatei:
- Datensatzzeigerposition Hauptdatei sichern
- Transaktion beenden
- Query 1 bis x wieder öffnen
- (Transaktion wird ja automatisch gestartet)
- Datensatzzeigerposition Hauptdatei wiederherstellen
- Daten anzeigen // das musste sowieso passieren

Im Einzelplatzbetrieb eventuell möglich, aber vom Ansatz her schon mal grundfalsch.

Da hat kein Fenster was damit zu tun, sondern nur die zuständige Query. Ob die jetzt in einem anderen Fenster liegt oder Datenmodul ist komplett egal, du musst die Logik ja wo unterbringen und dir den entsprechen Zugriffsweg schaffen. Das hast du ja, sonst könnte kein Benutzer mit den Daten was machen.

Fenster in dem Sinne, das ich in jedem Fenster eine eigene Connection/Transaction habe, um die Daten voneinander abzuschotten.

Wie gesagt, die Logik aus früheren Zeiten hat weiterhin Bestand .

Nur wie? Ist mein Problem jetzt Lazarus, Freepascal oder Firebird-spezifisch?


Zu den Versuchen, mit den Optionen zu testen erstelle ich einen neuen Post.

[Joh]

Ich habe mal getestet:

die Optionen der Connection und der Transaktionen sind:

Code: Alles auswählen

IBConnection.Options
[scoExplicitConnect]
[scoApplyUpdatesChecksRowsAffected] //=> dürfte nicht mit den automatischen Transaktionen zu tun haben.

SQLTransaction
[stoExplicitStart]
[stoUseImplicit] //=>  Laut Objektinspektor von TIBConnetion nicht unterstützt; scheint das Standardverhalten zu sein.

Test1:

Code: Alles auswählen

IBConnection.Options := [];
SQLTransaction.Options := [stoExplicitStart];
//=> Error: attempt to implicitly start a tansaction on Connection "IBConnection", Transaction "SQLTransaction".
//=> Query nicht geöffnet

Test2:

Code: Alles auswählen

IBConnection.Options := [scoExplicitConnect];
SQLTransaction.Options := [stoExplicitStart];
//=> Error: attempt to implicitly start a tansaction on Connection "IBConnection", Transaction "SQLTransaction".
//=> Query nicht geöffnet

Test3 (Standardverhalten):

Code: Alles auswählen

IBConnection.Options := [];
SQLTransaction.Options := [];
//SQLTransaction.Active: true
//=> Query geöffnet

Test4:

Code: Alles auswählen

IBConnection.Options := [scoExplicitConnect];
SQLTransaction.Options := [];
//SQLTransaction.Active: true
//=> Query geöffnet

SQLTransaction.Options := [stoExplicitStart] scheint also vorauszusetzen, das ich explizit vor einer Abfrage eine Transaktion manuell starte.
SQLTransaction.Options := [] die Transaktion wird automatisch gestartet, sobald ich eine Query öffne.
Die Connection-Optionen haben mit dem Verhalten nichts zu tun.


=> Mit den Options von TSQLTransaction scheine ich die automatischen Transaktionen nicht ausschalten zu können.

[af0815]

Die Optionen die du suchst liegen in der Query unter Options. Wenn dort sqoAutoCommit abgedreht ist, so sollte eine manuelle Steuerung der Transaktionen nichts im Wege stehen.

Ich verwende aus beruflichen Gründen nur die MSSQL-Connection, deswegen habe ich für die anderen Connections nicht die Erfahrung. Ich habe nur festgestellt, das das sqoAutoCommit auch nicht ganz astrein ist, weil bei Stored Procedures es nicht funktioniert weil es per Design immer ein Select/Update/Insert benötigt und ein EXEC ignoriert - ist aber per Design so gewollt. Damit funktionieren mache Stored Procedures wo Daten geändert werden einfach nicht, weil immer ein Rollback automatisch erzwungen wird. Weil die Transaktion zwar automatisch gestartet wird - aber per Design - nie abgeschlossen. IMHO ein Bug, der Developer sagt per Design. Meiner Meinung nach sollte die dann nicht gestartet werden und einen Fehler schmeissen. Das ist eine solcher halbgaren Sachen, die man wissen muß, weil stehen tut es nirgends.

[Joh]

wäre ja schön...

Aber bei mir ist bei allen Queries sqoAutoCommit deaktiviert.
Da scheint das Problem nicht zu liegen.

für einen Test mit einer anderen Datenbank - mir schwirren da Postgres und MariaDB im Kopf - fehlt mir aktuell die Motivation.
Also vor allem die, das ganze Projekt umzustellen ;-(