Table Lock beim INSERT

[klaushaidinger 0]

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!

 

[NilsK 2.934]

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

[klaushaidinger 0]

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

[NilsK 2.934]

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