![]() |
Re: IB-Transaktionen
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:
Zitat:
|
Re: IB-Transaktionen
Zitat:
|
Re: IB-Transaktionen
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. |
Re: IB-Transaktionen
Tja, muss dann doch noch mal zu den Transaktionen nachfragen.
Nachdem ich wie unten beschrieben meine Daten in den SQL-Server schreibe
Delphi-Quellcode:
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.
if DM.IBTransaction.InTransaction then
DM.IBTransaction.CommitRetaining; //usw 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 |
Re: IB-Transaktionen
Wer hat Dir denn das mit dem "CommitRetaining" erzählt ? :shock:
|
Re: IB-Transaktionen
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. |
Re: IB-Transaktionen
hallo hajo,
arbeitest du mit den zeos? lass einfach mal das Retaining weg , also einfach commit raik |
Re: IB-Transaktionen
hallo kiar,
nein, ich arbeite mit den Interbase-Komponenten von Delphi7 Gruß Jochen |
Re: IB-Transaktionen
dann mache einen harten commit
|
Re: IB-Transaktionen
Hier mal eine kurzer Ausschnitt aus meinem schlauen Buch. :mrgreen:
Zitat:
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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:36 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz