SQL/Access-ODBC-Block-Problem: Meldung "ODBC-Aktualisierung fehlgeschlagen"

[KlebeKalle]

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:
[/I]
"ODBC-Aktualisierung in einer verknüpfter Tabelle „Produktstammdaten“ fehlgeschlagen"
[Microsoft][ODBC-SQL-Server-Driver]Timeout abgelaufen (#0)
[/I]
-> 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…

[O. Helper]

Hallo KlebeKalle,

so ganz nachvollziehen kann ich es derzeit nicht.
Die Konstellation über ODBC verknüpfte Tabellen ist nicht gerade der Hit, geht aber schon.

Was mich "stört" ist das "SQL Guard LOCKCHECK" in den Fehlermeldungen.
Kurz gegooglet: http://www.thsfock.de/Art_SQLGuard_howto.htm
Kann es sein, das ihr da noch irgendeine Zusatz-App habt, die da mit rein werkelt? Dann darf man sich auch nicht wundern ....

An den ODBC Verknüpfungen gibt es nicht viel zum Einstellen.
Ich würde aber mal in der Formular-Einstellung unter "Datensätze sperren" nachsehen, ob da was <> "Keine Sperrungen" drin steht.

Für Zugriffe auf SQL Server via ODBC sind "Pass-Through" Abfragen besser geeignet.

Terminalserver

Dein nächstes Problem.
Unsere ERP Software nutzt auch noch Access als Frontend, aber immer hin schon als ADP/ADE.
Und rate mal: Unter TS bekommt jeder User seine eigene Kopie des Frontends zur Verfügung gestellt, d.h. eine Access-Datei ist immer max. von einem User in Benutzung; weil es anderes einfach eher nur schief geht und Probleme bereitet.

[KlebeKalle]

Was mich "stört" ist das "SQL Guard LOCKCHECK" in den Fehlermeldungen.
Kurz gegooglet: http://www.thsfock.de/Art_SQLGuard_howto.htm
Kann es sein, das ihr da noch irgendeine Zusatz-App habt, die da mit rein werkelt? Dann darf man sich auch nicht wundern ....

Nein, eigentlich nicht... das einzige was auf dem SQLServer zugreift ist die MDB über ODBC

An den ODBC Verknüpfungen gibt es nicht viel zum Einstellen.
Ich würde aber mal in der Formular-Einstellung unter "Datensätze sperren" nachsehen, ob da was <> "Keine Sperrungen" drin steht.

ICh hab jetzt nicht alle Formulare geprüft, aber in den Hauptformularen, die am meisten benutzt werden, ist überall "Keine Sperrungen" ausgewählt.

Ich habe jetzt Testweise jedem Benutzer eine Eigene MDB zur fervügung gestellt, aber was ich bis jetzt festgestellt habe ist, dass es keine Veränderung gibt.

"Pass-Through" Abfragen sind problematisch, da die Abfragen dadurch ja alle aktualisiert werden müssen und die Syntax für SQL eine andere ist als in Access und es dadurch zu Problemen kommt. das heißt ich müsste jede Abfrage neu schreiben. Leider fehlt mir anscheint das nötige Know-How um die Vielzahl der komplexen Abfragen neu zu gestalten.

Gibt es evtl ein "Converter" der automatisch die Syntax anpasst?