KlebeKalle
Grünschnabel
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
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 terminiert
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. Haben hier SQL-Einstellungen Priorität und wo kann man diese setzen ?
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 terminiert
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. Haben hier SQL-Einstellungen Priorität und wo kann man diese setzen ?
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…
