4
SQL-Access-ODBC-Block-Problem Meldung ODBC-Aktualisierung fehlgeschlagen
Hallo liebe SQL-Profis, Ich verzweifele bei nachfolgendem Problem:
Wenn der gleiche (oder ein anderer) Benutzer aus mind. 2 Access-Frontend-Formularen auf dieselbe SQL-Backend-Tabelle zugreift (oder eine darauf aufbauenden Access-Frontend-Abfrage),
wird der Prozess geblockt. Die entsprechende Tabelle kann dann nicht mehr editiert werden.
z.B. gleichzeitige Bearbeitung von:
Form: Produktstammdaten
Form: Bestellungen (Kombinationsfeld mit Abfrage auf Stammdaten)
Form: Stücklisten ((Kombinationsfeld mit Abfrage auf Stammdaten)
Im anderen Fall (z.B. Kontakt-Tabelle aus verschiedenen Formularen bearbeiten) treten diese Blocks nicht auf
SQL-Guard Log: Blocksituation
Wenn meherer User auf die gleiche Tabelle zugreifen:
SQL Guard LOCKCHECK: Der blockierende Prozess 53 besteht weiterhin! Alter min: 30 Sekunden
SQL Guard LOCKCHECK: Der blockierende Prozess 53 besteht weiterhin! Alter min: 40 Sekunden
Nach 30 sek. Wird das Editieren der Produktstammdaten wieder freigegeben und die Änderung übernommen oder es folgt nach ca. 60 sek. die Meldung:
"ODBC-Aktualisierung in einer verknüpfter Tabelle „Produktstammdaten“ fehlgeschlagen"
[Microsoft][ODBC-SQL-Server-Driver]Timeout abgelaufen (#0)
-> Wahrscheinlich wenn mehrere Benutzer auf die Tabelle zugreifen und die Sperrung nach einem bestimmten Zeitlimit nicht aufgehoben werden kann (Wo kann man das einstellen ?)
Änderungen im SQL-Guard bzgl. Zeitintervall (Check- & Killintervall) scheinen keinen Einfluß zu haben...
Ich habe von Deadlocks, no locks, row level locking und dirty reads gelesen, weiß aber nicht wo ich das Einstellen kann.
Die Abfragen laufen aus dem Access-Frontend heraus, da Views auf dem SQL-Server nicht editierbar sind und teilw. Probleme bei der Einbindung in Access haben.
Eine Umstellung auf ADP ist bei ca. 500 Abfragen zu aufwendig.
Software:
Frontend: Access 2003 SP3 auf Windows 2003 Server SP2 Terminalserver mit ca 15 Benutzern
Backend: MS SQL 2000
Verknüpft über ODBC
ODBC-Treiber
ODBCJT32.DLL Version 4.00.6305.00
SQLNCLI.DLL Version 2005.90.3042.00
SQLSRV32.DLL Version 2000.86.3959.00
der Frontend (4 GB-Ram) ist über Gigabit Netz mit dem SQL-Server (2 GB-Ram) verbunden
Anmerkung: Es gibt nur einen Useraccount, der auf den SQL-Server zugreift
Ich wäre sehr dankbar, wenn mir hier jemand Licht in meine Dunkelheit bringen kann…
Wenn der gleiche (oder ein anderer) Benutzer aus mind. 2 Access-Frontend-Formularen auf dieselbe SQL-Backend-Tabelle zugreift (oder eine darauf aufbauenden Access-Frontend-Abfrage),
wird der Prozess geblockt. Die entsprechende Tabelle kann dann nicht mehr editiert werden.
z.B. gleichzeitige Bearbeitung von:
Form: Produktstammdaten
Form: Bestellungen (Kombinationsfeld mit Abfrage auf Stammdaten)
Form: Stücklisten ((Kombinationsfeld mit Abfrage auf Stammdaten)
Im anderen Fall (z.B. Kontakt-Tabelle aus verschiedenen Formularen bearbeiten) treten diese Blocks nicht auf
SQL-Guard Log: Blocksituation
BLOCKING Statement : Auswahl in Form: Bestellungen
Parameter : 0 - SQL : SELECT "PNIdNr" ,"PN" ,"Bezeichnung" ,"Beschreibung" ,"BemerkungenIntern" ,"EK" ,"VK" FROM "dbo"."PDB" WHERE NOT(("PN" IS NULL ) ) ORDER BY "dbo"."PDB"."PN" ,"dbo"."PDB"."Bezeichnung" - Typ : Language Event
BLOCKED Statement : Editieren im Formular „Produkt-Stammdaten“
Parameter : 0 - SQL : UPDATE "dbo"."PDB" SET "BeschreibungEK"=N'1',"UpdateDat"='20091007 00:00:00.000',"UpdateUser"=N'rwe' WHERE "PNIdNr" = 31206 AND "TS" = 0x00000000027F7853 - Typ : Language Event
SQL Guard LOCKCHECK: Der blockierende Prozess 53 besteht weiterhin! Alter min: 10 Sekunden
SQL Guard LOCKCHECK: Der blockierende Prozess 53 besteht weiterhin! Alter min: 20 Sekunden
SQL Guard LOCKCHECK: Der blockierende Prozess 53 wurde terminiertWenn meherer User auf die gleiche Tabelle zugreifen:
SQL Guard LOCKCHECK: Der blockierende Prozess 53 besteht weiterhin! Alter min: 30 Sekunden
SQL Guard LOCKCHECK: Der blockierende Prozess 53 besteht weiterhin! Alter min: 40 Sekunden
Nach 30 sek. Wird das Editieren der Produktstammdaten wieder freigegeben und die Änderung übernommen oder es folgt nach ca. 60 sek. die Meldung:
"ODBC-Aktualisierung in einer verknüpfter Tabelle „Produktstammdaten“ fehlgeschlagen"
[Microsoft][ODBC-SQL-Server-Driver]Timeout abgelaufen (#0)
-> Wahrscheinlich wenn mehrere Benutzer auf die Tabelle zugreifen und die Sperrung nach einem bestimmten Zeitlimit nicht aufgehoben werden kann (Wo kann man das einstellen ?)
Änderungen im SQL-Guard bzgl. Zeitintervall (Check- & Killintervall) scheinen keinen Einfluß zu haben...
Ich habe von Deadlocks, no locks, row level locking und dirty reads gelesen, weiß aber nicht wo ich das Einstellen kann.
Die Abfragen laufen aus dem Access-Frontend heraus, da Views auf dem SQL-Server nicht editierbar sind und teilw. Probleme bei der Einbindung in Access haben.
Eine Umstellung auf ADP ist bei ca. 500 Abfragen zu aufwendig.
Software:
Frontend: Access 2003 SP3 auf Windows 2003 Server SP2 Terminalserver mit ca 15 Benutzern
Backend: MS SQL 2000
Verknüpft über ODBC
ODBC-Treiber
ODBCJT32.DLL Version 4.00.6305.00
SQLNCLI.DLL Version 2005.90.3042.00
SQLSRV32.DLL Version 2000.86.3959.00
der Frontend (4 GB-Ram) ist über Gigabit Netz mit dem SQL-Server (2 GB-Ram) verbunden
Anmerkung: Es gibt nur einen Useraccount, der auf den SQL-Server zugreift
Ich wäre sehr dankbar, wenn mir hier jemand Licht in meine Dunkelheit bringen kann…
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 128079
Url: https://administrator.de/contentid/128079
Ausgedruckt am: 21.11.2024 um 22:11 Uhr
4 Kommentare
Neuester Kommentar
Moin,
das Problem kommt aus den Comboboxen.
Is schon ne weile her, aber ich glaube in den Parametern der Abfrage kannst Du das Sperrverhalten einstellen.
ODER du Wandelst die Abfragen in SQL-Passthru um und fügst ein "with no locks" ein das Statement ein.
ODER du verwendest Views mit "no lock" und bindest die in Access ein (so haben wir das gemacht)
lg,
Slainte
das Problem kommt aus den Comboboxen.
Is schon ne weile her, aber ich glaube in den Parametern der Abfrage kannst Du das Sperrverhalten einstellen.
ODER du Wandelst die Abfragen in SQL-Passthru um und fügst ein "with no locks" ein das Statement ein.
ODER du verwendest Views mit "no lock" und bindest die in Access ein (so haben wir das gemacht)
lg,
Slainte
Das mit den Views, bzw Pass-Through, hatte ich auch schon im Sinn... nur leider fehlt mir an dieser Stelle das nötige Know-How um die ca 2700 komplexen Abfragen die das System umfasst anzupassen.
... gibt es nicht eine Art Converter oder Compiler, der das ganze von AccessSyntax auf SQL umconvertiert?
... gibt es nicht eine Art Converter oder Compiler, der das ganze von AccessSyntax auf SQL umconvertiert?
... gibt es nicht eine Art Converter oder Compiler, der das ganze von AccessSyntax auf SQL umconvertiert?
MIr ist nichts bekannt. Wir hatten das "damals" mit dem Tool "Praktikant 1.0" gelöst (~16.000 Tabellen, ~10.000 Abfragen) 
also das Hauptproblem, neben der PErformance, ist eigentlich, dass an unterschiedlichen stellen geblockt wird...
gibt es im SQL Server 2000 irgendeine Einstellungsmöglichkeit, dass wenn ein Block entsteht einfach alles so schnell wie möglich gelöst wird, oder halt abgebrochen wird, ohne dass dann überall im Frondend die Mitarbeiter sitzen und warten müssen, weil alles stockt?
gibt es im SQL Server 2000 irgendeine Einstellungsmöglichkeit, dass wenn ein Block entsteht einfach alles so schnell wie möglich gelöst wird, oder halt abgebrochen wird, ohne dass dann überall im Frondend die Mitarbeiter sitzen und warten müssen, weil alles stockt?
