Abfragetimeout

[dabadepdu]

Beim Schließen des Formulars

Das ist nicht eindeutig.
Es gibt Code und Events, die eine eindeutige Antwort liefern würden. Warum schreibst Du das nicht explizit?
Und wo wird geprüft oder festgelegt, ob es überhaupt eine Änderung gab? In dem Code, den Du gezeigt hast, jedenfalls nicht.
Wenn es nur manchmal passiert, sind alle diese Dinge und ihre Reihenfolge von Bedeutung.

Aber egal, wenn es ein Trigger wird, spielt es keine Rolle mehr, funktioniert zuverlässig und schnell.

 

[Babsi]

Hallo dabadepdu,

ich glaube wirklich das war das Problem. Ich habe das Update beim Schließen des Form nun raus genommen

 

[Babsi]

Ja, das war wohl das Problem.

Vielen tausend Dank für Dein Engagement

​

 

[dabadepdu]

das war wohl das Problem

Du solltest sämtlichen Code auf solche Konstrukte prüfen. In Access geht es wahrscheinlich nicht viel anders, als es mit VBA zu machen. Aber mit einem Server dahinter sparst Du Ressourcen und Nerven, wenn Du das alles auf Trigger umstellst, nicht nur da, wo es weh tut.

Wenn es ein großes Projekt ist, kannst Du auch die Suche im Code mittels VBA automatisieren. Oder Du suchst im Datenmodell nach allen Spalten, die ein Datumstyp haben und nach Änderungsdatum "klingen"- Createdate wäre u.U. ein ähnliches Problem, je nach Umsetzung, eigentlich sollte das ja über einen Defaultwert laufen, der natürlich im Datenmodell definiert sein muss und Änderungsschutz braucht, also ohne Trigger, ohne Updatestatement.

 

[t-sql]

@Babsi Ich meinte damit, das Du das SQL Statement aus deinem Formular direkt auf dem SQL Server ausführen sollst um dort die Performance zu prüfen. Aber dein Problem hat sich ja mittlerweile erledigt.

 

[Babsi]

Hallo dabadepdu,

leider war es das doch nicht

Das ist ein ganz einfaches SELECT, von einer einzigen Tabelle.

SELECT COMPANY_ID, CGROUP_ID, BANK_ID, USER_ID,
COUNTRY_ID, COMPANY_SHORT, COMPANY_NAME1, COMPANY_NAME2,
COMPANY_STREET, COMPANY_PLZ, COMPANY_CITY, COMPANY_TEL,
COMPANY_FAX, COMPANY_MOBIL, COMPANY_EMAIL, COMPANY_EMAILRG,
COMPANY_EMAILSUPPORT, COMPANY_EMAILKB, COMPANY_WWW, COMPANY_PRIVADR,
COMPANY_HRB, COMPANY_HRBAMT, COMPANY_GEWSCHEIN, COMPANY_GEWAMT, COMPANY_PERSONR,
COMPANY_PERSOAMT, COMPANY_USTID, COMPANY_ANZFIL, COMPANY_VERBAND, COMPANY_ISAKTIV,
COMPANY_isINSO, COMPANY_isBIG, COMPANY_OWNER, COMPANY_OWNER_BIRTH, COMPANY_GF,
COMPANY_GF_BIRTH, RESELLER_ID, COMPANY_GF_EMAIL, COMPANY_WHENNEW, COMPANY_LASTCONTACT,
COMPANY_BWNR, COMPANY_IBAN, COMPANY_BIC, COMPANY_MANDATSNR, COMPANY_MANDATSDATE, COMPANY_ACCOUNT,
COMPANY_ACCNAME, COMPANY_BLZ, COMPANY_DoUmsStat, COMPANY_StatEmailAdr, COMPANY_StatEmailAdr2, COMPANY_StatEmailAdr3,
COMPANY_SL_MANAGE, COMPANY_SL_SEND_ONEFIL, COMPANY_SL_SEND_ALLFIL, COMPANY_SL_SEND, COMPANY_SL_MAILADR, COMPANY_SL_MAIL,
COMPANY_GS_TEXT, COMPANY_LS_TEXT, COMPANY_SUMTERM, COMPANY_PAYPROVI, COMPANY_ISPROBLEM,
COMPANY_ZGbestaetigt, COMPANY_MEMO, CreditorID, Creditor_BusinessAccountChek, ContractProved,
YaerEstablished, changeDate, RECHTSFORM_ID, ERWERBSART_ID
FROM dbo.COMPANY

Das ist auf dem SQL Server natürlich schnell(00:00:01).

Das changeDate, da sollte eigentlich rein, wenn etwas an der Tabelle geändert wurde. Ist vom Typ 'Date' und darf Nullwerte enthalten.
ich lass das jetzt erst mal aussen vor.
Für alle Bit-Felder(Access: Ja/Nein) gibt es einen default Wert= ((0)), ich habe gehört da kann es zu Problemen kommen wenn dies nicht der Fall, also der default Wert nicht existiert.

Und, das komische ist, es läuft dann eine ganze Zeit lang, wo man denkt, das wars, dann aber wieder dieses TimeOut.
Ich versuche das jetzt über ein View, die kann ich aber in Acces nicht bearbeiten obwohl das eigentlcih gehen sollte, da nur eine einzige Tabelle.

Tja, ich weiß echt nicht weiter

 

[Babsi]

Hallo dabadebdu,

das ist das Recosrdest des Formulars. Ein Update explizit gibt es nicht. Der entsperchende Datensatz wir geändert und das sollte es gewesen sein, meisstens klappt das auch super.
Ich habe auf jeden Fall die View zum laufen bekommen, aber da erscheint iregndwann das gleiche Problem. Und ich denke ob nun View oder direkt Tabelle ist auch egal.
Aus dem Select soll ich einen Trigger machen?
Ok... Ich kenn mich mit den Triggern nicht so aus, was genau soll der denn anstossen?

 

[Babsi]

hm, ich hab nun gelesen ein Trigger direkt auf ein Select geht nicht, da sollte man eine View benutzen

 

[t-sql]

ich lass das jetzt erst mal aussen vor.
Für alle Bit-Felder(Access: Ja/Nein) gibt es einen default Wert= ((0)), ich habe gehört da kann es zu Problemen kommen wenn dies nicht der Fall, also der default Wert nicht existiert.

Tja, ich weiß echt nicht weiter

Du kannst bei Tabellen einen Default Wert mit geben (Specify default values for columns - SQL Server). Heißt die Bit Felder sind immer 0 außer du änderst es halt durch ein Insert oder Update. Allerdings sollte das der Tabelle bzw. Abfrage egal sein ob Defaultwerte existieren oder nicht solange die Spalte NULL sein kann.

 

[dabadepdu]

Ich verstehe gerade nicht das Problem. Du hast das Update auf das Datum entfernt UND keinen Trigger als Ersatz dafür eingebaut und du hast trotzdem den gleichen Timeout?

Grundsätzlich:
Du solltest nicht mit einem Recordset auf einer sehr großen Tabelle arbeiten, sondern besser auf einer Abfrage. Aber dabei musst Du die Abfrage auch dazu nutzen, die Datenmenge drastisch zu reduzieren, im Idealfall auf einen Datensatz. Eine Umstellung auf Abfrage ohne Where Clause bringt nichts.
Die Abfrage sollte m.E. eine Pass Through Abfrage sein.
Passthrough Abfrage impliziert die Entfernung von Access spezifischen Funktionen in den Queries.
Datentypen Datetime.. und Bit: Diese Typen sind sensibel, bei Datetime der Bereich Millisekunden. Diese Probleme bringen vermutlich aber eher harte Fehler als Timeouts.
Gerade bei diesen Datentypen können diese Probleme auch durch veraltetet, 2nd-best ODBC Treiber oder falschen / ungünstigen Compatibility Level des Servers entstehen.

Wenn Du auf Anhieb nicht weißt, welchen Compatibility Level Du nutzt und warum, und gleiches für den ODBC Treiber, solltest Du dem auch nachgehen. Also den besten ODBC Treiber für dein Setting finden und den höchst möglichen/ besten Compatibility Level.

 

[t-sql]

Gerade bei diesen Datentypen können diese Probleme auch durch veraltetet, 2nd-best ODBC Treiber oder falschen / ungünstigen Compatibility Level des Servers entstehen.

Wenn Du auf Anhieb nicht weißt, welchen Compatibility Level Du nutzt und warum, und gleiches für den ODBC Treiber, solltest Du dem auch nachgehen. Also den besten ODBC Treiber für dein Setting finden und den höchst möglichen/ besten Compatibility Level.

Der ODBC Treiber kann das Problem. Der Comp. Level nicht. Is ja eine Migration von Access -> SQL Server. Daher ist der Comp. Level immer "richtig". Bei einer Migration von SQL Server auf eine höhere SQL Server Version kann das ein Problem sein. Aber nur wenn der Level angehoben wird und der Hersteller nix an seinen Querys macht. Microsoft garantiert die Lauffähigkeit alter Datenbanken bzw. deren Querys auf neuen Version wenn der Comp. Level erhalten bleibt.

 

[dabadepdu]

Is ja eine Migration von Access -> SQL Server. Daher ist der Comp. Level immer "richtig".

Da bin ich nicht sicher. Wenn ich das richtig im Kopf habe, ist der MSSQL Server nicht grad die neueste Version. Also vielleicht irgendwas, was schon da war, und es ist eine "Dev."- bzw. "Test"-Umgebung, wo ich mal in Frage stellen würde, ob da alles "original" ist.
Wie auch immer, kann man alles nachschauen, ändern, optimieren.