IB-Transaktionen

[Albi]

Es spielt keine Rolle ob du 1 oder 2 Transaktionen für lesen und schreiben verwendest. Wenn Du aber die Sperrmechanismen der IB nutzt wirst Du merken, da du diese mit per Hand/Code verwalten must.

Bsp. Nehmen wir an du hast 5 User und du benutzt den IdleTimer und hast den Trans-Editor auf "write consistency" gesetzt. Dann must du dich darum kümmern, den IdleTimer wieder zurückzusetzen, da ansonsten nach einer bestimmten Zeit die Daten gespeichert o. verloren gehen. Vergiesst Du den Schreibschutz rauszunehmen stehen die anderen User auf dem Schlauch, da sie an die Daten nicht rankommen, da Du ja noch einen X-Lock auf der DB hast.

Aus diesem Grunde habe ich 2 Transactionen, eine zum lesen und eine zum schreiben, einfach nur um die Fehler gleich im Vorfeld auzuschließen. Ich gehe damit sogar noch weiter, ich fülle in meinem Prog CBoxen mit Werten aus der DB und sogar dafür habe ich meine eigene Transaction.

Es geht hier also nicht um sinnvoll oder nicht sinnvoll, sondern vorrangig - in meinem Fall - Fehler in der Programmierung zu vermeiden. Wenn es dir besser gefällt Quake, dann kannst Du weiterhin nur eine Transaction für jedes Form nehmen.

Das ist in meinen Augen auch kein Problem, wie schon gesagt, muss das jeder für sich entscheiden ob er es braucht oder nicht.

Ich habe mir diese nur aus einem Buch abgeschaut und komme so gut damit zu recht.

Zitat von Jelly:

Zitat von Quake:

-Transaktion 1 wird gestartet
-Daten wedern gelesen
-Transaktion 1 wird beendet
-Daten werden bearbeitet
-Transaktion 2 wird gestartet
-Daten werden geschrieben
-Transaktion wird beendet

Das ist so falsch. Nach Beenden von Transaktion 1 können keine Daten bearbeitet werden, und dann erst die Transaktion 2 gestartet werden. Änderungen an Daten passieren im Falle von Interbase IMMER innerhalb einer Transaktion.

Da versteh ich jetzt nicht. Wieso soll das nicht gehen, du hohlst den DS aus der DB schreibst sie in Edits und kannst die Transaction schließen. Dann änderst Du die Daten speicherst sie. Schlecht sieht es nur aus, wenn die Datenmenge mehr als ein DS zurück gibt, dann sollte man die Tansaction schon offen lassen.

Zitat von Quake:

Dann nehme ich eine IBQuary, IBTable oder IBSQL und weise ihnen die Database incl. Transaktion zu. Was ist jetzt aber unübersichtlich?

Wenn Du eine große Anwendung hast, wie Kiar schon geschrieben hast, weißt Du irgendwann nicht mehr welchen Zustand deine Transaction hat. Das kannst Du zwar mit einem SoftCommit umgehen aber das Müllt Dir nur die DB zu, irgendwann wird sie so langsam sein, dass sich fast nichts mehr bewegt. Also ab und zu richtig Hard-Commiten und die DB zu reinigen.

[Jelly]

Zitat von Albi:

Da versteh ich jetzt nicht. Wieso soll das nicht gehen, du hohlst den DS aus der DB schreibst sie in Edits und kannst die Transaction schließen.

Vielleicht hab ich auch nur falsch verstanden, was mit "Daten bearbeiten" gemeint ist. Ich bin davon ausgegangen,daß durch das Bearbeiten die Daten in der DB geändert werden, und nicht daß sie nur in einem Edit Feld sichtbar gemacht werden. Dann stimmts natürlich.

[Albi]

Vielleicht mal ein Beispiel aus meinem Prog, so wie das handhabe.

Im DM liegen 1 Trans-read, 1 Trans-write, 1 Trans-CBoxen (wird auch in anderen Form verwendet), 1 SP, 1 Query.

- ich melde mich
- öffnen Form (onCreate CBoxen füllen [Trans-CBoxen öffnen & nach füllen gleich wieder schließen])
- in Edit1 was eintragen suchen klicken
- Trans-read öffnen
- Anfrage an DB schicken
- Ergebnis > 0 Trans-read bleibt Active
- Daten in die Edit eintragen
- Daten ändern
- Speichern klicken
- Trans-read schließen
- Trans-write öffnen
- Daten an DB senden
- Trans-reaf öffnen um die geänderten Daten aus DB zu holen

So sieht mein Schema im groben aus.

[HaJo]

Tja, muss dann doch noch mal zu den Transaktionen nachfragen.

Nachdem ich wie unten beschrieben meine Daten in den SQL-Server schreibe

Delphi-Quellcode:

    if DM.IBTransaction.InTransaction then
       DM.IBTransaction.CommitRetaining;
    //usw

kann ein zweiter Client die so vorgenommenen Änderungen nicht sehen. Erst nach erneutem Abmelden von der Datenbank siend dort dann die geänderten Daten zu sehen.

Ist bestimmt eine blöde Frage - aber wie aktualisiere ich denn die Interbase-Tabelle. Blosses Schließen und Öffnen bleibt ohne Wirkung.

Bin tatsächlich etwas ratlos.

mfg
Jochen

[Hansa]

Wer hat Dir denn das mit dem "CommitRetaining" erzählt ?

[HaJo]

Tag Hansa,

nun, ich denke das diese Variante dazu gedacht ist, ein Commit auf die DB zu machen sie aber nicht zu schließen. Hab ich hier im Forum gefunden.

Die Änderungen werden ja auch für andere Anwendungen, wie z.B. die IB-Console in der DB sichtbar, nur nicht in einem zweiten Client von mir.

[kiar]

hallo hajo,

arbeitest du mit den zeos?

lass einfach mal das Retaining weg , also einfach commit

raik

[HaJo]

hallo kiar,

nein, ich arbeite mit den Interbase-Komponenten von Delphi7

Gruß
Jochen

[kiar]

dann mache einen harten commit

[Albi]

Hier mal eine kurzer Ausschnitt aus meinem schlauen Buch.

Zitat:

Über die TIBTransaction-Methode Commit wird ein sogenannter Hard-Commit ausgelöst, der die aktuelle Ergebnismenge der Select-Abfrage auf dem Interbase-Server verwirft. Ab diesem Zeitpunkt gib es also keine Datenmenge mehr, die IBX anzeigen kann. Um das automatische Schließen der TIBCustomDataset-Nachfolger zu verhindern, muß man dafür sorgen, dass die Ergebnismenge auf dem Server offen bleibt. Durch dem Aufruf der Methode CommitRetaining wird dies erreicht. Der Interbase beendet zwar die Transaction und startet eine neue Transaction, es werden aber automatisch alle Resourcen der alten Transaction inklusive der Ergebnismenge in den Kontex der neuen Transaction übernommen.

Quelle: Interbase Datenbankentwicklung mit Delphi (Andreas Kosch)

@HaJo: Das sollte eigentlich alle deine Fragen beantworten, Du arbeitest einfach mit einer alten Datenmenge.

Um die aktuelle Datenmenge aus der DB zu erhalten mach ein Commit und öffne danach die Transaction und sende ggf. eine neue Abfrage an die DB, dann sollten deine Daten auf dem neusten Stand sein.