[MSSQL] Row gelocked

[PopiPipo]

Ik heb hier een probleem waar ik maar geen oplossing voor kan vinden.

Ik heb een MSAccess interface gekoppeld aan SQL Server via ODBC
Hiermee worden gegevens opgezocht en gemuteerd.

Wanneer ik via een insert query (binnen access) een record toevoeg aan de tabel gaat dit prima, echter als ik hierna een veld van de nieuwe record direct wil muteren krijg ik de melding dat een andere user dezelfde record probeerd te wijzigen en de wijziging niet kan worden doorgevoerd.

Als ik dezelfde mutatie via een update query of direct via enterprise manager via "Open table" uitvoer gaat het wel gewoon.
Het vreemde aan de zaak is dat alle andere records in de tabel wel direct te muteren zijn...

Tevens heb ik zo een aantal andere tabellen met identieke structuur waarbij ,ook na een insert in voornoemde situatie , zich verder geen problemen voordoen.

De verdere feiten;

Rechten zijn volgens mij het probleem niet aangezien de andere records wel gewoon te muteren zijn.
Ook na weghalen van de record (via een delete Query) en weer toevoegen via de insert geeft weer dezelfde verschijnselen.
Killen van alle processen die op dat moment worden uitgevoerd op deze tabel, heeft geen effect.

Misschien heeft iemand dit ook al eens meegemaakt ?

[Tomatoman]

Het lijkt erop dat Access zijn table cursor nog niet heeft vrijgegeven. Sluit je de insert query in Access wel netjes af na gebruik? Ik kan me voorstellen dat deze situatie optreedt als je de insert query vanuit een paar regels code aanroept en de recordset daarna niet vrijgeeft. Gevolg: geheugenlek + record lock.

[PopiPipo]

Bedankt voor de reply...

Daar dacht ik dus ook al aan, maar alles wordt normaal gesloten na afloop...
Verder heb ik geen problemen bij andere tabellen met dezelfde structuur.

Het is een insert query SQL string die wordt samengesteld uit variabelen
deze vormt dan de definitie voor een querydef.
Vervolgens gebruik ik het .execute command om de query te runnen, waarna ik de database netjes afsluit met db.close...

De enige manier om dit te voorkomen is door de record direct via enterprise manager in te voeren....dan heb ik geen locks op de rij en is er niets aan de hand.

Is er soms een manier om de lockstatus en locksoort van de rij te achterhalen ?

[Verwijderd]

Misschien dat je last hebt van de "Lazy writer" van Access. Probeer het statement

Visual Basic:

  DBEngine.Idle DBRefreshCache

eens om alle schrijfoperaties te flushen.

[PopiPipo]

Helaas heeft dit geen effect

[napel25]

Misschien kun je proberen de insert, updates en deletes met pass-through queries te doen. Dan heb je verder weinig last van hoe Access er mee om gaat.

[PopiPipo]

Tsja ...da's natuurlijk ook 'n idee.. , grote kans dat dat werkt inderdaad...

Ik ga het maandag direct proberen; ben nu helaas niet op m'n werk...

I'll keep you posted....

[PopiPipo]

Nou, t'is opgelost hoor...

Nadat bleek dat ook pass-through queries niet hielpen, maar stap voor stap alles uitgeplozen;

Het blijkt dat het probleem zat in de ODBC-bitveld combinatie.

Ik had in mijn tabel een aantal bitvelden waarbij NULL's waren toegestaan.
Dit ging via de ODBC-connectie falikant fout en bleef de row gelocked , zelfs nadat de operatie was afgesloten.

De oplossing bleek een default value (0) en geen NULL's toestaan instellen in de properties van alle bitvelden.

Ik hoop dat ik hiermee iemand een hoge bloeddruk kan besparen....

[ Voor 3% gewijzigd door PopiPipo op 25-07-2005 20:24 ]

[Annie]

offtopic:
Over welke versie van sql server hebben we het eigenlijk? Ik dacht me te herinneren dat in sql7 er inderdaad wat vaagheden rond bitvelden waren. Via de EM kon je een bitveld niet als nullable opgeven, terwijl dat via de QA weer wel gewoon mogelijk was.

[PopiPipo]

Het was SQL server 8.0 (2000 dus)