Zitat von
Jasocul:
Natürlich kann man nicht alle Fehler vorhersehen. Aber schön wäre es schon.
Dein Fall den du beschreibst ist kein DeadLock.
hmm, schon möglich, nur gibt genau bei diesem Beispiel Firebird diese Fehlermeldung zurück.
Mann kann es ja auch schön in der IBConsole ausprobieren, einfach zwei Transaktionen starten und und zwei Updates, dann kommt genau diese Fehlermeldung "deadlock - update conflicts with concurrent update."
und genau dies ist mein Problem, mir ist schon klar, das ich das per Programm lösen kann, aber das auf die schnelle bei über 2000 Units durchgehen, wür dich mir genre für den Anfang sparen ...
Zitat von
Jasocul:
Dein Problem kannst du vermutlich durch eine Einstellung bei
FB oder den Zugriffskomponenten beheben. Bei
FB bin ich aber nicht der Spezi, kann dir also nicht sagen wo. Aber normalerweise gibt es Einstellungen, die das Verhalten für diesen Fall beeinflussen (z.B.: ignorieren, überschreiben, abbrechen)
Ja genau soetwas würd ich brauchen
Zitat von
Jasocul:
Ich persönlich würde die Kontrolle aber nicht aus der Hand geben und im Programm prüfen, ob und welcher Fall vorliegt.
Ist sicher besser aber ob das Zeit/Ergebnis dafürspricht ... ich möchte nur einige knifflige selbst machen, den rest sollte die Komponente oder der Server per Default einfach Überschreiben.
Zitat von
Jasocul:
Die Vorgehensweise habe ich oben schon beschrieben. Ob die Änderungen durch ein Update-Statement oder durch einen Anwender entsteht, ist dabei nebensächlich.
Ist klar, das es nebensächlich ist, wollte nur klarstellen, das es mit dem "Lock-Zeit so kurz wie möglich zu halte" nicht wirklich was bringt, da ja keinerlei Useraction zwischen dem öffnen der Transaction in dem Commit liegt.