Deadlockopfer bei TDataset.Refresh

[TigerLilly]

Zitat von haentschman:

Wie kriege ich raus wer der Übeltäter ist?

Lass den Profiler mitlaufen, dann siehst du, welche SQL Statements abgesetzt werden.
Und vielleicht hilft das auch:
http://etutorials.org/SQL/...

[haentschman]

Zitat:

Wie kriege ich raus wer der Übeltäter ist?

Blöd ausgedrückt.
...ist mir eigentlich egal. Ich brauche eine Prüfung ob das Refresh ausgeführt werden kann.

Was ich probiert habe:

Query.Connection.InTransaction
Connection.InTransaction (was imho das gleiche ist)
Query.CanRefresh

Welche Möglichkeiten habe ich noch?

PS:
Das ist erst, seit ich das automatische Aktualisieren der Oberfäche eingebaut habe. Dadurch hat die Häufigkeit der Ausführung des Refresh deutlich zugenommen.

Zitat:

Lass den Profiler mitlaufen, dann siehst du, welche SQL Statements abgesetzt werden.

Da sehe ich doch nur welche Locks existieren. Aber nicht die "Konflikte" mit einem Refresh.
Trotzdem Danke.

[TigerLilly]

Das hat mit Transaktionen nur bedingt zu tun. Dein Problem sind LOCKs + die werden auch durch bloßes Lesen erzeugt. Die Locks können neben einzelnen ROWs auch ganze Seiten oder Tabellen umfassen + damit Sätze sperren, die mit der aktuellen Abfrage gar nichts zu tun haben. Siehe weiter vorne im Thread.

[haentschman]

Zitat:

Das hat mit Transaktionen nur bedingt zu tun. Dein Problem sind LOCKs

ich brauche Urlaub.

Ich kann um das Refresh einen leeren try/except Block machen.

[TigerLilly]

Zitat von haentschman:

Ich kann um das Refresh einen leeren try/except Block machen.

Du kannst eine Schleife machen + das Refresh - nach einer kleinen Pause - solange wiederholen, bis es klappt. Aber da muss man sehr aufpassen, dass man den Server nicht mit lauter Wiederholungsversuchen in die Knie zwingt.