Abfragetimeout

[Babsi]

Hallo zusammen,

ich habe unsere altes Access Backend nach SQL Server migriert. Viele Views erstellt viel SP's.
Alles gut schon soweit.

Nun gibt es ein Fomrular, mit Kundendaten. Auf diesem sind etliche Felder, wenn ich nun diese Kundendaten bearbeite und das Form schließen will, bekomme ich die Fehlermeldung

Abfragetimeout überschritten.

Ich habe aus der zugrunde liegenden Tabelle(also das RS) schon eine Abfrage gemacht.
Leider ändert das auch nichts. Es ist auch so, dass es mal funktioniert und mal nicht, das lässt meine Vermutung wachsen, das es gar nicht unbedingt was mitden Einstellungen zu tun hat. Ich hatte das zuvor im MS Access gepostet, da ich eigentlich einstellen wollte:

Wo kann ich denn diesen Wert "Kommandotimeourt

im neuen Access ändern, wenn es denn überhaupt der Fehler ist.

Vielleicht kannmir hier jemand einen Tipp geben.

 

[bdittmar]

MS SQL Server Remote Query Timeout ?

Server configuration: remote query timeout - SQL Server

Learn about the remote query timeout option. See how it determines the number of seconds that a remote operation can take before SQL Server times out.

learn.microsoft.com

oder

ODBCTimeout-Eigenschaft

Office VBA-Referenzthema

learn.microsoft.com

mfg BD

 

[Babsi]

Hallo bdittmar,

ich danke Dir vielmals, das zweite hatte ich schon versucht. Braucht dann ewig lange und das Ergebnis ist das selbe.
Das erste(Server Configuration...), super! Habe ich auch sofort ausprobiert: Auf '0' gesetzt, also aus. Aber auch hier, das selbe Ergebnis.

USE FENG;
GO

EXECUTE sp_configure 'remote query timeout', 0;
GO

RECONFIGURE;
GO

 

[t-sql]

@Babsi Die erste Einstellung bezieht sich auf Linked Server. Hat also mit deinem Problem nix zu tun. Das erste was du tun solltest ist das generierte T-SQL Script aus dem Formular auf dem SQL Server über das SSMS auszuführen. Ist es im SSMS schnell -> Problem am Frontend, wenn nicht, Problem bei der Abfrage, also Ausführungsplan anschauen.

 

[Babsi]

Hallo t-sql,
es ist schon eine Weile her, ich würde das Thema aber trotzdem noch einmal aufgreifen wollen.
Das Problem ist leider immer noch nicht gelöst. Was mir aufgefallen ist, das es mal auftritt und mal nicht.
Und ich habe mir die Tabelle, also die ehemals Accesstabelle, auf dem Server nun einmal angesehen. Es liegen da jeden Menge Constraints auf den Spalten. Vor allem auf den BIT(Ja/nein) Feldern. Das ist ja eigentlich eher gut, da ich gelesen hatte, dass es Probleme geben kann eben bei diesen Datentyp.
Was genau meinst Du bitte mit

generierte T-SQL Script aus dem Formular

als Recorset des Forms habe ich eine in Access erstellet Abfrage. Eine View oder eine PassTrough kann ich nicht bearbeiten, aber ganeu das ist erforderlich.
Im Grunde ist das eine einzige Tabelle, das sollte doch schnell gehen.

 

[Babsi]

...oder können diese Constrainst auch hinderlich sein beim aktualisieren? Ich bin im Moment verunsichert .....

 

[dabadepdu]

Du müsstest schon irgendwelche Angaben liefern, was da eigentlich passiert und was es ist. Ein Formular, ein Endlosformular, Subformular(e) ... (ich hab jetzt nicht kreuz und quer in den anderen Posts geschaut)
Edit und Post, Edit und gar nichts (autopost), nur schauen, ..
Wieviel Datensätze angezeigt werden insgesamt (master, detail), welche davon alle editierbar sind, editiert werden, ..
Und vor allem, wenn dahinter irgendwelche Updates liegen, wie die realisiert sind. Handarbeit (VBA), (automatisch) generierte Updatestatements (was tsql vielleicht meint) bzw. Updates auf der Query (Datenquelle allgemein, also Table oder Query), angegebene oder erkannte Primärschlüssel oder wenn nicht, dann evtl. eine große Where Bedingung über alle Felder ...
Ich kenne es eher von ADO (.NET), dass die generierten Statements manchmal unglücklich, unbrauchbar sind und eine manuelle Angabe Wunder wirkt. Ein hinreichend schlechtes Statement kann so um Faktoren in der Performance verbessert werden.

Ganz zuletzt auch mal die Frage, was die Natur der Daten ist. Ein Sachbearbeiter, der sich um ein Fall kümmert, kommt sich selten mit dem Kollegen in die Quere (konkurrierende Updates). Ein Verkäufer, der eine limitierte Menge Zeugs verkauft dagegen sehr gerne..

Am Ende findet der Server den Datensatz vielleicht nicht mehr, weil jemand anders ihn bereits geändert hat. Oder er kann für das Update nicht gesperrt werden (kein Row Level Locking). Hängt alles mit den Fragen zuvor zusammen.

Meine Access Zeiten sind zum Glück lange her, daher kann ich nur grob mit Erfahrungswerten auf diese Probleme eingehen. Ich erinnere mich allerdings dunkel, dass diese Serverumstellung nicht auf einer besonders neuen Version von MSSQL gelandet ist. Wahrscheinlich nicht empfehlenswert, wenn es wirklich so ist.

 

[Babsi]

Es gibt z.B. diesen Constraint:

ALTER TABLE [data].[COMPANY] WITH NOCHECK ADD CONSTRAINT [SSMA_CC$COMPANY$COMPANY_MEMO$disallow_zero_length] CHECK ((len([COMPANY_MEMO])>(0)))
GO

ALTER TABLE [data].[COMPANY] CHECK CONSTRAINT [SSMA_CC$COMPANY$COMPANY_MEMO$disallow_zero_length]

Aber die Spalte selber lässt Nullwerte zu

 

[Babsi]

Hallo dabadepdu,

ok, mach ich gern, sorry.

Es ist eine goße Tabelle, zuvor war einfach die Tabelle angegeben. Ich habe nun nur die Spalten genommen und eine Abfrage hinterlegt.
Anzahl der Spalten sind: 67
Diese sollen veränderar sein. Es gibt keine WHERE Klausel aber euf dem Formular liegt ein Filter beim öffnen, der dem PK entspricht.
Der PK ist im Formular enthalten(Autowert) eine Timestamp Spalte gibt es auch.

Ich aktualisiere beim Schließen per Execute eine Datumsspalte in der Tabelle. Mehr findet eigentlich nicht statt.

Ganz zuletzt auch mal die Frage, was die Natur der Daten ist. Ein Sachbearbeiter, der sich um ein Fall kümmert, kommt sich selten mit dem Kollegen in die Quere (konkurrierende Updates). Ein Verkäufer, der eine limitierte Menge Zeugs verkauft dagegen sehr gerne..

Es sind Kundendaten, die von lediglich 2 Mitarbeitern bearbeitet werden und dann immer unterschiedliche Kunden.

Am Ende findet der Server den Datensatz vielleicht nicht mehr, weil jemand anders ihn bereits geändert hat. Oder er kann für das Update nicht gesperrt werden (kein Row Level Locking). Hängt alles mit den Fragen zuvor zusammen.

Das ist ja alle noch auf dem Testsystem, das kann eher nicht passieren.

 

[dabadepdu]

Weiß nicht, wie in Sqlserver blobs auf NULL geprüft werden. Vielleicht steht irgendwas nicht druckbares drin, Zeilenumbruch oder BOM oder was auch immer.
Den Filter auf PK würde ich immer machen. So, dass beim Öffnen immer eine leere Menge dargestellt wird (z.B. id =-1 bei positiven, steigenden Autoinc Werten), und so, dass beim Schließen (nach dem Update) gar nicht mehr geöffnet wird.
Von Tabelle auf Abfrage zu wechseln, ohne eine gute (schnelle) Where Clause bringt auch glaub ich kaum was (gar nichts?). Ein paar Spalten weniger macht auch keinen Unterschied. U.u. spielen die Blob Spalten eine Rolle, in der Abfrage raus lassen und nur im Form holen, bei Bedarf, nachdem der Datensatz selektiert wurde.
Wie tsql ebenfalls sagte, müssen die Abfragen in der Console schnell sein, so wie sie vom Frontend kommen. Wenn es auf dem Server (Console) nicht schnell ist, dann sicher auch nicht in Access.
Wenn Du lange Wartezeiten hast, kannst Du auch mal im Query Cache schauen, welche Abfragen da grad laufen oder ankommen. Weiß nicht, wie man den per SQL bei SQLServer abfragt, gibt es aber bestimmt.

 

[dabadepdu]

Ich aktualisiere beim Schließen per Execute eine Datumsspalte in der Tabelle.

Das könnte schon ein Problem sein. Zeig mal den Code.
Wenn die Query selbst im Form in den Edit Mode geht, könntest Du in der Spalte vor dem Schließen einfach den Datumswert eintragen. Wenn Du ein konkurrierendes Statement dafür abschickst, kann es sich mit der Query im Schreiblese Modus beißen, also Row Lock oder sowas von der Query, plus Execute Update Datum, ergibt u.U. einen Konflikt, je nach Timing der Details beim Schließen.

Du aktualisierst einfach so? Weil man mal auf den Datensatz geschaut hat?
Nicht, weil etwas geändert wurde?

 

[Babsi]

Hallo dabadepdu,

ja, wenn was geändert wurde, wird für diesen DS ein Upadte mit aktuellem Datum in diese Spalte geschrieben, sollte so sein, ja..

Dim LID As Long

' Feststellen, wurde was geändert?
LID = Me.COMPANY_ID

CurrentDb.Execute "UPDATE COMPANY SET COMPANY.changeDate = Now WHERE COMPANY_ID = " & LID & "", dbSeeChanges

 

[dabadepdu]

Wo/wann wird das aufgerufen?
Ich denke aber, diesen Code solltest Du einfach löschen und daraus einen Trigger auf dem Server machen. Analog für alle ähnlichen Konstrukte in anderen Tabellen. Das ist nicht nur ressourcenschonender- dieser Effekt kann sich in Summe sehr positiv auswirken, zumindest wenn nicht nur 2 Leute an der DB hängen-, sondern auch 100% konsistent. (Statt, ok, wir hatten zwar Änderungen im Datensatz, aber leider blieb das Updatestatement für das Aktualisierungsdatum unterwegs im Stau hängen- was also wann wirklich aktualisiert wurde, kann ich nicht exakt sagen)

 

[dabadepdu]

P.S.
Im Testsystem kannst Du das Statement sowieo mal rausnehmen, um es als Ursache ein- oder auszuschließen.
Wie auch immer, all dieser Kram sollte aus Access raus und zu Triggern im Server werden. Du stellst ja nicht von PKW auf LKW um, behälst aber die PKW Reifen, weil noch was Profil drauf ist.

 

[Babsi]

Wo/wann wird das aufgerufen?
Ich denke aber, diesen Code solltest Du einfach löschen und daraus einen Trigger auf dem Server machen. Analog für alle ähnlichen Konstrukte in anderen Tabellen. Das ist nicht nur ressourcenschonender- dieser Effekt kann sich in Summe sehr positiv auswirken, zumindest wenn nicht nur 2 Leute an der DB hängen-, sondern auch 100% konsistent. (Statt, ok, wir hatten zwar Änderungen im Datensatz, aber leider blieb das Updatestatement für das Aktualisierungsdatum unterwegs im Stau hängen- was also wann wirklich aktualisiert wurde, kann ich nicht exakt sagen)

Beim Schließen des Formulars