Firebird, ApplyUpdates, Deadlock

[mrdembo1]

Servus,

Hab meinen Fehler in folgender Beispiel Anwendung nachgebaut.

Das Problem dass ich nun habe ist, wenn man den selben Record im ersten Grid
sowie im zweiten Grid bearbeitet man eine Fehlermeldung bekommt!

Meine Lösung dazu war momentan die Datenbankverbindung zu trennen und dann sofort wieder neu aufzubauen

Bitte um Hilfe

Code: Alles auswählen

 
procedure TForm1.Button1Click(Sender: TObject);
begin
  SQLQuery1.ApplyUpdates;
  SQLTransaction1.CommitRetaining;
  ShowMessage('Ende');
end;
 
procedure TForm1.Button2Click(Sender: TObject);
begin
  SQLQuery2.ApplyUpdates;
  SQLTransaction2.CommitRetaining;
  ShowMessage('Ende');
end;    
 

[hde]

Auch bei der besten RAD-IDE reicht für eine mehrplatzfähige DB-Anwendung die "Clicktechnik" nicht aus, etwas Programm muss muss schon sein.
hde

[mrdembo1]

Auch bei der besten RAD-IDE reicht für eine mehrplatzfähige DB-Anwendung die "Clicktechnik" nicht aus, etwas Programm muss muss schon sein.
hde

Sorry aber ich versteh diese aussage irgendwie nicht?

[hde]

du musst verhindern dass 2 Leute gleichzeitig den gleichen Datensatz verändern, wie denkst du denn soll das sonst gehn? der erste ändert Feld1 und der zweite Feld2 und dann ist Feld1 wieder zurückgesetzt auf alten Inhalt? Und ein deadlock darf schon gar nicht vorkommen.

[mse]

Siehe auch http://www.firebirdfaq.org/faq151/

[mrdembo1]

Ja also gleichzeitig wird der Datensatz ja nicht verändert (nacheinander)
1. User A ändert was im ersten Grid
2. ApplyUpdates
3. Commit wird ausgeführt

4. User B ändert was im zweiten Grid
5. ApplyUpdates
6. Commit wird ausgeführt

Nur wieso ist der Datensatz nach einem Commit nicht wieder bearbeitbar?
Erst wenn ich die zweite Verbindung wieder neu lade, wird mir der neue Datensatz angezeigt und ich kann ihn dann wieder bearbeiten.
Gibt es keine Event das mir die Änderungen der DB anzeigt?
Und wieso ist der Datensatz nach dem Commit noch gesperrt?

[hde]

Gibt es keine Event das mir die Änderungen der DB anzeigt?

Nein
vor jedem Update sollte der einzelne Datensatz neu gelesen und für Änderungen durch andere gesperrt werden.
Wenn du ihn nicht neu einliest machst du Änderungen von User A wieder rückgängig, willst du das wirklich?
hde

[mrdembo1]

Gibt es keine Event das mir die Änderungen der DB anzeigt?

Nein
vor jedem Update sollte der einzelne Datensatz neu gelesen und für Änderungen durch andere gesperrt werden.
Wenn du ihn nicht neu einliest machst du Änderungen von User A wieder rückgängig, willst du das wirklich?
hde

Ahhm Nein natürlich nicht

Wie Aktualisiere ich den den denn Datensatz? (Timer und alle paar Sekunden das Grid neu laden )
Und überhaupt wie lädt man das Grid neu? Refresh->geht nicht!!

[mse]

Eine neue Transaktion starten, also "<transaction>.commit" oder "<transaction>.rollback" statt "<transaction.commitretaining". Eine andere Möglichkeit ist das "transaction isolation level" zu ändern http://www.firebirdsql.org/manual/isql- ... tions.html default ist "READ WRITE + WAIT + SNAPSHOT" (entspricht ungefähr SERIALIZABLE) was zum erlebten deadlock führt. <transaction>.options = 'isc_tpb_read_committed' entspricht dem SQL statement "SET TRANSACTION READ COMMITED". Dies sollte das Lesen der in der anderen Transaktion commitedten records erlauben.
http://www.firebirdsql.org/refdocs/lang ... trans.html

[hde]

Ein Grid für Updates zu verwenden ist mMn keine gute Idee, und Autoedit auch nicht.
Bevor man einen Datensatz per Edit zum Ändern freigibt, MUSS er neu eingelesen und SOLLTE für andere Updates gesperrt werden.
Also, bevor du die Daten zum Edit freigibst, sollte das geschehen.