Schreibzugriff auf eben erzeugten Datensatz innerhalb einer Transaktion scheitert

[Sinspin]

Hallo,

ich habe beim Zugriff auf eine Tabelle innerhalb einer Transaktion das Problem das ich auf einen eben erzeugten und gespeicherten Datensatz nicht mehr schreibend zugreifen kann.
Fall im einzelnen:
Ich schütze eine komplexe Änderung an der Datenbank durch eine Transaktion um Müll bei auftretenden Fehlern zu verhindern.
Innerhalb der Transaktion wird mit einer Tabelle (ADSTable) ein neuer Datensatz erstellt (kopie eines bestehenden) und gespeichert.
An anderer Stelle muss der eben erstellte Datensatz nochmals bearbeitet werden. Dazu kommt eine andere Tabelle zum Einsatz die für genau den Zweck erstellt wird.
In dem Moment wie der erzegte Datensatz bearbeitet werden soll bekomme ich die Meldung : (5035) : "The requested lock could not be granted. The file or record may be locked by another user."
Der Datensatz ist mit Sicherheit nicht offen, wird nicht von einem anderen Nutzer bearbeitet und wurde auch nicht zwischenzeitlich wieder gelöscht.
Alle Tabellen verwenden für ihren Zugriff die gleiche Connection, die erstellten, aber noch nicht commiteten Datensätze lassen sich lesend öffnen und anzeigen. Eine Transaktion in der bestehenden Transaktion (Nested Transaction) lößt das Problem auch nicht.

Alles funktioniert wunderbar wenn ich ohne Transaktionen arbeite. Es wäre mir halt nur lieber mit Transaktion damit es kein Müll in der DB gibt wenn es aus irgend einem Grund mal knallt.

Ich würde mich echt freuen wenn mir jemand sagen könnte dass das eben so ist. Schöner wäre natürlich ein Lösung :wink:

Danke für eure Hilfe.

[mquadrat]

Sicher, dass beide Zugriffe in der gleichen Transaction stattfinden?

[Sinspin]

Jep, da bin ich mir 100% sicher. Denn alle Tabellen verwenden die gleiche Connection und bei ADS sind Transaktionen Connection basiert.

[joachimd]

Es ist beim ADS nicht möglich, mit zwei verschiedenen Komponenten innerhalb derselben Transaktion den gleichen Datensatz zu ändern. Die Datensatzsperren innerhalb der Transaktion bleiben bestehen, bis die Transaktion abgeschlossen wird.
Abhilfe schafft hier SQL, da SQL commands über eine Connection serialisiert werden und somit nicht in eine Nebenläufigkeit kommen können.

[Sinspin]

Hallo Joachim,

ich habe darauf gehofft das du mir antwortest. Allerdings bin ich mit deiner Antwort echt nicht zufrieden, auch wenn ich wohl fürs erste damit leben muss.
Was ich nicht verstehe, warum, wenn Transaktionen über die Connections verwaltet werden, trotzdem ein Bezug zu den Tabellenkomponenten hergestellt wird der dann dafür sorgt das jede Komponente als eigenständiger Nutzer gilt. Sehe ich mir das ganze in der Remote Server Info an sehe ich aber lediglich Connections die eine Reihe offener Tabellen haben, teilweise auch mehrfach. Irgendwelche unterschiedlichen Nutzerhandle sind da nicht zu sehen.
Wäre es nicht deutlich sinnvoller es so zu machen das alles was in der Connection passiert, egal wie oft welche Tabelle angefasst wird, einfach in den gleichen Puffer läuft?
Ich würde sagen, es wäre ein klasse Todo dieses Problem mit der nächsten Version zu beheben.

[joachimd]

Zitat:

Zitat von Sinspin (Beitrag 1075294)

Wäre es nicht deutlich sinnvoller es so zu machen das alles was in der Connection passiert, egal wie oft welche Tabelle angefasst wird, einfach in den gleichen Puffer läuft?

Damit würde man sich als Nachteil einhandeln, dass nichts mehr parallel abgearbeitet werden kann. Ich glaube, die Nachteile würden den Nutzen deutlich überwiegen, vor allem, weil man durch einen kleinen Umbau (alles über SQL) das ganze einfach umgehen kann.

[Sinspin]

Umstellen auf SQL ist aber an dieser Stelle so gut wie unmöglich. Ich greife auf mehrere komplexe Module zu die hier zusammenarbeiten müssen. Das erste legt einen Teil der Daten an die das nächste bearbeitet und neue anlegt. Weitere Module überarbeiten die Daten. Da alle Module auch in anderen Breichen benötigt werden kann ich sie nicht einfach ändern.

Was ich nicht verstehe, wenn es mit SQL klappt das ich mehrfach schreibend zugreifen kann, warum ist es dann nicht auch mit Tabellen hinzubekommen. Eine Tabelle ist doch in der Regel einfacher gestrickt als ein SQL Statement, warum soll dann eine Tabelle zum Posten von Änderungen das ganze nicht auch via SQL hinbekommen? Und zwar einfach so, ohne das es dem Entwickler auffällt. Selbst wenn das nur Innerhalb von Transaktionen passiert und nur wenn ein entsprechendes Property gesetzt ist.
Warum soll ich eine Erweiterung schreiben die mit Sicherheit nicht nur mir nutzen würde? So darf dies jeder ders braucht für sich selber tun, nur leider längst nicht so effizient, weil nicht weit genug "unten".

[jobo]

Ich kann Dir nur empfehlen, Dich mit Client-/ Server-Prinzipien vertraut zu machen. Ein Server gewährleistet Transaktionssicherheit, genau dafür ist er (u.a.) da. Ein Client- besonders mehrere- sollte sich darauf verlassen können. Clients, die das "eigenmächtig" verwalten, sind m.E. meist zum Scheitern verurteilt, entsprechende Clientfunktionalität fragwürdig (ok, vlt. nicht, wenn man einen App.Server baut).
Wenn also klar ist, dass es komplexe Funktionen gibt, die mehrfach (an mehreren Stellen) verwendet werden, ist das ein klarer Fall für zentrale Serverlogik, via SQL, Stored Procedure oder App.Server.

[Sinspin]

Ich habe schon eine ganze Reihe von Aufgaben in Stored Procedures und Trigger verschoben. Allerdings bisher immer recht kleine Sachen oder Berechnungen die auf der DB einfach flotter laufen. Etwas derart Komplexes, bei dem der Nutzer vorher Einfluss auf die Bildung der Ergebnisse nehmen muss kann ich da nicht ohne weiteres unterbringen. Ich müsste Tabellen schaffen über die die Daten übergeben werden können. Würde ich nur Teilbereiche verschieben brächte es mir hingegen garnichts, da ich sicherstellen muss das die gesammte Aufgabe als eine einzige Transaktion durchgeht oder eben nicht.
Aber, ich danke Dir für Deine Antwort, denn sie hat mich wachgerüttelt. Und so werde ich in Zukunft mehr darauf achten Probleme auf der DB und nicht im Programm zu lösen.