Jump to content

Table Lock beim INSERT


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Recommended Posts

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!

 

Link to comment

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

Link to comment

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

 

Link to comment
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...