klaushaidinger 0 Posted October 28, 2020 Report Share Posted October 28, 2020 Hallo Zusammen, ich habe folgendes Problem: Ich verbinde mich via ODBC auf eine SqlServer (2016) Datenbank - dort gibt es LAND und LAND_PLZ. Kurz der Aufbau. LAND (land_no varchar(4) primary key, bezeichnung varchar(50), ....) LAND_PLZ (land_no varchar(4) - foreign key ref. LAND, plz varchar(6), ort varchar(50), .....) Und die beiden Statements: INSERT INTO land (land_no, bezeichnung) values ('AT4', 'Testland') INSERT INTO land_plz ( land_no, plz, ort ) values ('AT4', '4020', 'Linz' ) Wenn ich die Statements direkt im ManagementStudio ausführe, funktioniert es ohne Probleme. Via ODBC (im Debugger meines Programms) geht das 1. Statement durch, das 2. nicht, weil es anscheinend durch LAND gesperrt ist. Wenn ich gleich nach dem 1. Statement ein COMMIT mache, geht es. Das möchte ich aber verhindern, da ich ansonsten den kompletten Sourcecode umschreiben müsste. Wenn ich den ForeignKey lösche, geht es auch - aber auch das sollte nicht das Ziel sein :-/ Hat irgend jemand eine Idee? Vielen DANK! Quote Link to comment
NilsK 2,971 Posted October 28, 2020 Report Share Posted October 28, 2020 Moin, Ich bin kein SQL-Developer, aber soweit ich mich an das Thema erinnere, ist das der Sinn der Locks beim Insert. Die Lösung für solche Sperrkonflikte ist typischerweise, dass man ein Vorgehen strikt einhält, das diese vermeidet. In deinem Fall also der Commit der Transaktion, die die Sperre auslöst. Arbeitet die Applikation denn anders als der Beispielcode? Normalerweise sind Anweisungen beim SQL Server ja implizite Transaktionen, die auch sofort geschlossen werden. Das würde erklären, warum es im SSMS geht. Gruß Nils Quote Link to comment
klaushaidinger 0 Posted October 28, 2020 Author Report Share Posted October 28, 2020 Hallo Nils, danke für deine Antwort! Hintergrund ist ja, dass - sollte etwas schief gehen (DB-seitig oder auch mal inhaltlich) - ein ROLLBACK gemacht werden kann und somit alles Vorangegangene auch rückgängig gemacht wird - praktisch transaktionsgesichert. Würde ich immer gleich COMMITen, müsste ich mich ums Aufräumen kümmern Quote Link to comment
NilsK 2,971 Posted October 28, 2020 Report Share Posted October 28, 2020 Moin, tja ... wie gesagt, ich bin kein Developer, aber - meiner Kenntnis nach wirst du dich entscheiden müssen. Packst du mehrere (oder sogar "viele") Statements in einer Transaktion, dann hält SQL Server die Sperren so lange offen, wie die Transaktion andauert. In deinem Fall sperrt also durch den Foreign-Key-Constraint die eine Tabelle die andere. Da beide Anweisungen schreiben, hilft dir auch eine geringere Isolationsstufe nicht, die etwa einen Dirty Read zuließe. Gruß, Nils Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.