Query timeout expired

[MartinHan]

Hallo,

so kurz vor der Sylvestersause noch eine kurzee Frage:

Ich habe jetzt einiges an Stp und deren Aufrufen erstellt.
Läuft alles klasse.
Ich habe mir vorgenommen, das nicht für alle Zugriffe zu machen, aber so für zentralen Tabellen schon.
Jetzt stocke ich bei einer winzigen Stp mit nur einem Delete Statement:

alter PROCEDURE [dbo].[person_delete]
   -- Add the parameters for the stored procedure here
    @personid int
   ,@errmsg nvarchar(100) out 
   
AS
BEGIN
   -- SET NOCOUNT ON added to prevent extra result sets from
   -- interfering with SELECT statements.
   begin try
   SET NOCOUNT ON;

         
    -- Insert statements for procedure here
   print N'PK der zu löschenden Person:' + convert(nvarchar(10),@personid)
   delete from [dbo].[person] where personid = @personid

   print N'Anzahl DS:' + convert(nvarchar(10),@@rowcount)

   return @@rowcount
   
   end try

begin catch
    print N'Error: ' + ERROR_MESSAGE()
    set @errmsg = ERROR_MESSAGE()
   return -1
 END CATCH;
END

Der zenrale Teil der VBA Proc

 Dim cn As New ADODB.connection
  Dim cmd As New ADODB.Command
  Dim rc As Long

On Error GoTo myerror
             
    cn.ConnectionString = Forms![start menue]!tab_connstr
    cn.Open
   
    With cmd

             .ActiveConnection = cn
             .CommandType = adCmdStoredProc
             .CommandText = "person_delete"
             .Parameters.Refresh
             .NamedParameters = True
             .Parameters("@personid").Value = PersonId
             .Execute , , adExecuteNoRecords
             
    End With
     
   
    rc = cmd.Parameters(0)

Bei dem Ecexute bleibt er stehen, irgendwann erscheint dann die Meldung:

Query timeout expired

Wie gesagt, alle anderen Funktionen ob mit oder ohne stp laufen fehlerfrei. Auch wenn ich den Aufruf manuell auf dem Server mache, ratzfatz durch.
Ich habe auch bei dem cmd den wert connectiontimeout = 0, gesetzt.dann hat er sicht völlig aufgehängt.
Irgendwo steht da eine Ampel auf rot, obwaohl man ja in diesen Tagen dieses Wort kaum noch ausspechen darf...

Ich vermute fast, das das mit den Verbindungen zusammenhängt, die ich mir so gebastelt habe. und offen gesagt, auch noch nicht so ganz verstanden habe. Aber was kümmenrts, wenn läuft...
Aber für heute klinke ich mich mal aus.

Bis zum nächsten jahr!

Martin

[Bitsqueezer]

Hallo Martin,

nicht alles, was da so passiert, wird Dir in Access auch angezeigt.

Hattest Du nicht mal gesagt, daß Du Deine Datenbank mit "CASCADE DELETE" großzügig designt hast?

D.h., wenn Du eine Person aus einer Tabelle löschst, deren ID sicherlich sehr oft in einer DB verwendet wird, dann löschst Du eben nicht nur den einen Datensatz, sondern u.U. aus einer Menge anderer Tabellen.

Das wiederum bedeutet, daß die Voraussetzungen dafür in den anderen Tabellen gegeben sein müssen. Nur weil Du die Person löschst und deren Daten dazu, heißt das nicht, daß es nicht in den anderen Tabellen noch referentielle Integrität gibt, die dort das Löschen verhindert.

Darüber hinaus kann natürlich auch, wenn ein anderer Benutzer noch mit den Daten arbeitet, ein Dead-Lock entstehen, dann wartet die Ausführung Deiner SP ewig.

Das Thema ist nicht ganz trivial, hier mal eine Erläuterung von MS dazu:
https://learn.microsoft.com/de-de/sql/relational-databases/sql-server-deadlocks-guide?view=sql-server-ver16
https://learn.microsoft.com/de-de/sql/tools/sql-server-profiler/analyze-deadlocks-with-sql-server-profiler?view=sql-server-ver16

Ich würde damit beginnen, erst mal die Kommunikation zwischen Access und SQL Server einzusehen, um nachzuvollziehen, was da tatsächlich passiert, auch weil man da bisweilen Fehler angezeigt bekommt, die nicht an Access weitergereicht werden oder die in der ADO-Error-Auflistung stecken, die die meisten nicht abfragen.

Das wäre der SQL Server Profiler:
https://learn.microsoft.com/de-de/sql/tools/sql-server-profiler/sql-server-profiler?view=sql-server-ver16

Der sollte bereits installiert sein und über SSMS aufrufbar sein.

In neueren SQL Servern ist es noch etwas einfacher, da kannst Du ganz unten in der Liste von SSMS XEvents finden, das ist der moderne Ersatz für den Profiler, etwas einfacher in der Bedienung. Das Ergebnis ist sehr ähnlich. Wenn auf Deinem SQL Server nicht viel los ist, mußt Du nicht viel einstellen, ansonsten gilt für beide, am besten auf Deine Datenbank anhand des Namens filtern und ggf. das Frontend.
Dann ist die Anzahl der Events geringer und man findet das gesuchte leichter.
Wenn das Tool läuft, startest Du Deine Prozedur von VBA aus und schaust, was da so alles passiert.

Dann lohnt auch ein Blick in den Activity Monitor, den Du auch in SSMS in der Objektliste findest (je nach Version u.U. auch in den Menüs):
https://learn.microsoft.com/en-us/sql/relational-databases/performance-monitor/activity-monitor?view=sql-server-ver16

Der zeigt Dir alle laufenden Verbindungen und Tasks und Du kannst sehen, ob ein Prozess "hängt", den Du hier auch killen kannst bei Bedarf. Sollte man aber nur, wenn es keinen anderen Weg gibt.

Nicht zuletzt sollte man auch berücksichtigen, daß ein DELETE auch Trigger auslöst, wenn denn welche definiert wurden. Auch hier können Fehler enthalten sein, die das Problem verursachen.

Auch wenn CASCADE DELETE bequem sein mag, man sollte es mit Bedacht einsetzen. Eine ganze Datenbank quer alles auf diese Weise zu behandeln, kann jede Menge Probleme erzeugen, und ist auch gefährlich, wenn man das mal versehentlich anstößt und danach die halbe Datenbank leer ist. Eine "CASCADE-Bremse" in Form einer m:n-Tabelle zwischendurch kann durchaus hilfreich sein. Auch sollte man über SET DEFAULT nachdenken, weil man vielleicht eine Person löschen muß, aber nicht z.B. die Bestellungsdaten verlieren will. (Gilt auch für CASCADE UPDATE natürlich, das wird/sollte aber seltener eingesetzt werden.)

Wünsche noch einen guten Rutsch!

Gruß

Christian

PS: Ein Tip am Rande: Wenn Du Codes in Code-Tags im Forum einschließt, wird der Code deutlich lesbarer. Als Fließtext ist es anstrengend zu lesen.

[MartinHan]

Hi,

das CASCADE Delete ist bewußt so gewählt. Ich frage auch voher, ob das den Nutzern klar ist, sie sind auch soweit geschult.
Das ganze passiert jetzt in der Entwicklungsumgebung da bin ich alleine...

Wenn ich die stp auf dem Server aufrufe, läuft sie ja durch.
In diesen Fall waren das sogar Testpersonen, die gar keine weitere Verknüpfung haben.
Wenn ich einen SQL-Delete in Access als SQL Befehl absetze, geht der auch durch.

Fragen über Fragen...

Martin

[Bitsqueezer]

Hallo Martin,

frohes neues Jahr wünsche!

Dann würde ich mal den Profiler/XEvents-Weg gehen und sehen, was genau da passiert.

Gruß

Christian

[MartinHan]

Hallo,

ich habe jetzt ertmal auf die alte Version zurückgestellt.
Ich denke, ich werde mir mal eine kleine TestDB anlegen und dann die CRUD-Befehle systematisch duchgeben.

Die jetztige Anwendung ist einfach zum Testen und lernen zu groß...

Mal was für lange Winterabende.

M.

[PhilS]

Darüber hinaus kann natürlich auch, wenn ein anderer Benutzer noch mit den Daten arbeitet, ein Dead-Lock entstehen, dann wartet die Ausführung Deiner SP ewig.

Der Begriff "Deadlock" ist in diesem Satz nicht passend.

Eine Lösch- oder Aktualisierungsabfrage wartet bis zum Timeout (oder ewig ohne Timeout), wenn einer der betroffenen Datensätze durch eine andere Verbindung gerade gesperrt ist. Da ist i.d.R. kein Deadlock involviert.

Wenn tatsächlich ein Deadlock besteht, dann sollte die SQL Server DB Engine das eigentlich bemerken und dann eine der beiden Transaktionen, die sich in einer Deadlock-Situation befinden, beenden (Rollback) und für die Verbindung eine Fehlermeldung mit klarem Hinweis auf die Deadlock-Situation ausgeben. - Hier entsteht keine längere Wartezeit für die andere Verbindung.