Supportnet / Forum / Datenbanken
Abfrage funzt nich...hiiilfeee!!!
Frage
hallo,
ich habe eine aktualisierungsabfrage, die das feld "Kundendaten.zuständiger Verkäufer" auf "ohne Verkäufer" zurücksetzt, wenn in tabelle "Kontakte" das datum des feldes "Erstellungs-Datum" älter als vier monate ist:
UPDATE (Kunden INNER JOIN Kontakte ON Kunden.[Kunden-Nr] = Kontakte.[Kunden-Nr]) INNER JOIN Kundendaten ON Kunden.[Kunden-Nr] = Kundendaten.[Kunden-Nr] SET Kundendaten.[zuständiger Verkäufer] = "ohne Verkäufer"
WHERE (((Kontakte.[Erstellungs-Datum])<Date()-120));
leider funzt die abfrage nicht zuverlässig, bei manchen aktuellen einträgen im datumsfeld wird der zuständige verkäufer trotzdem zurückgesetzt, und wenn kein eintrag da ist, passiert nix. die abfrage wird beim öffnen der datenbank ausgeführt. die abfrage flöht 104000 einträge durch mit steigender anzahl...
was ist da falsch? bitte, bitte, ist superdringend....
Antwort 1 von Hinki27
Kann es sein, dass bei den falschen Aktualisierungen die Kunden noch kein Erstellungs-Datum haben? In diesem Fall nimm bitte in die WHERE-Klausel noch
AND (Not (Kontakte.[Erstellungs-Datum]) Is Null)
auf. Im übrigen, ich willnicht kleinlich sein, aktualisierst du die Daten, die älter als 120 Tage sind, und nicht die, die älter als vier Monate sind, das geht aber auch...
AND (Not (Kontakte.[Erstellungs-Datum]) Is Null)
auf. Im übrigen, ich willnicht kleinlich sein, aktualisierst du die Daten, die älter als 120 Tage sind, und nicht die, die älter als vier Monate sind, das geht aber auch...
Antwort 2 von feldfunktion
hallo hinki27,
ja, 120 tage sind bei mir vier monate im durchschnitt...
mit dem nullwert leuchtet das ein, aber trotzdem müsste die abfrage doch funktionieren, wenn ein datum eingetragen ist.
kann das was mit der indizierung der felder "Erstellungs-Datum" und "Zuständiger Verkäufer" zu tun haben? damit die abfrage schneller läuft....ursprünglich hat sie nämlich funktioniert....
vielen dank erstmal, gruss, feldfunktion
ja, 120 tage sind bei mir vier monate im durchschnitt...
mit dem nullwert leuchtet das ein, aber trotzdem müsste die abfrage doch funktionieren, wenn ein datum eingetragen ist.
kann das was mit der indizierung der felder "Erstellungs-Datum" und "Zuständiger Verkäufer" zu tun haben? damit die abfrage schneller läuft....ursprünglich hat sie nämlich funktioniert....
vielen dank erstmal, gruss, feldfunktion
Antwort 3 von feldfunktion
das problem scheint komplizierter. die abfrage funktioniert nicht, unmittelbar nach einem neu eingetragenen Erstellungs-Datum. wird sie ausgeführt, nachdem alle die datenbank geschlossen haben und man sie dann neu öffnet, dann scheint es zu klappen.
die abfrage wird immer dann ausgeführt, wenn jemand die datenbank öffnet. vielleicht sollte man sie an einer anderen stelle ausführen lassen, wo wäre das klug? kann man da einen timer einbauen?
die abfrage wird immer dann ausgeführt, wenn jemand die datenbank öffnet. vielleicht sollte man sie an einer anderen stelle ausführen lassen, wo wäre das klug? kann man da einen timer einbauen?
Antwort 4 von Hinki27
Hallo feldfunktion,
auch eine MS Access-DB ist transaktionssicher, damit meine ich hier, dass Abfragen in einer Programmlogik sich in ihrer Funktion nicht gegenseitig beeinflussen.
Mir scheint es, nach deinen Ausführungen, du hast eine MS Access-DB auf einem Netzlaufwerk / freigegebenes Berzeichnis liegen, oder? Dies ist zwar laut MS erlaubt, auch im Mehrfachzugriff, habe ich aber die Erfahrung gemacht, dass es in solchen Konstellationen immer wieder zu Fehlern kommt.
Ich arbeite immer mit getrennten Datenbanken, einer Daten-Datenbank und einer Programmdatenbank. Dies hat den Vorteil, dass du deine Programmlogik jederzeit aktualisieren kannst, ohne dass die Anwender auf die neuen Features warten müssen. Der weitere Vorteil liegt darin, dass du deine Daten auch auf professionelle Datenbanken (MSSQL, mySQL, Oracle etc.) übertragen kannst, ohne die Logik anzupassen (na gut ohne ein paar kleine Anpassungen geht es nicht).
Dies sollte nur ein Tip sein, um den Fehler einzukreisen, keine Kritik.
Gruß
Ralf
auch eine MS Access-DB ist transaktionssicher, damit meine ich hier, dass Abfragen in einer Programmlogik sich in ihrer Funktion nicht gegenseitig beeinflussen.
Mir scheint es, nach deinen Ausführungen, du hast eine MS Access-DB auf einem Netzlaufwerk / freigegebenes Berzeichnis liegen, oder? Dies ist zwar laut MS erlaubt, auch im Mehrfachzugriff, habe ich aber die Erfahrung gemacht, dass es in solchen Konstellationen immer wieder zu Fehlern kommt.
Ich arbeite immer mit getrennten Datenbanken, einer Daten-Datenbank und einer Programmdatenbank. Dies hat den Vorteil, dass du deine Programmlogik jederzeit aktualisieren kannst, ohne dass die Anwender auf die neuen Features warten müssen. Der weitere Vorteil liegt darin, dass du deine Daten auch auf professionelle Datenbanken (MSSQL, mySQL, Oracle etc.) übertragen kannst, ohne die Logik anzupassen (na gut ohne ein paar kleine Anpassungen geht es nicht).
Dies sollte nur ein Tip sein, um den Fehler einzukreisen, keine Kritik.
Gruß
Ralf
Antwort 5 von Hinki27
Hallo feldfunktion,
hier eine andere Variante des UPDATE-Statements, probiere sie mal auf der großen Tabelle aus:
UPDATE Kundendaten SET Kundendaten.[zuständiger Verkäufer] = "ohne Verkäufer"
WHERE (((Kundendaten.zv)<>"ohne Verkäufer") AND ((Kundendaten.[Kunden-Nr]) In (select [Kunden-Nr] FROM Kontakte WHERE nz([Erstellungs-Datum],date()) < date()-120)))
damit werden nur die DS geändert, die älter als 120 Tage sind, ohne die, in denen im Datumsfeld NULL steht, in der folgenden sind auch die DS mit NULL im Datum berücksichtigt:
UPDATE Kundendaten SET Kundendaten.[zuständiger Verkäufer] = "ohne Verkäufer"
WHERE (((Kundendaten.zv)<>"ohne Verkäufer") AND ((Kundendaten.[Kunden-Nr]) In (select [Kunden-Nr] FROM Kontakte WHERE nz([Erstellungs-Datum],0) < date()-120)))
In beiden Fällen werden die, die bereits "ohne Verkäufer" eingetragen hatten nicht mehr berücksichtigt. Auf den Felder n [Kunden-Nr], [zuständiger Verkäufer] und [Erstellungs-Datum], sollte auf jedenfall ein Index liegen.
Vielleicht hilfts.
Gruß
Ralf
hier eine andere Variante des UPDATE-Statements, probiere sie mal auf der großen Tabelle aus:
UPDATE Kundendaten SET Kundendaten.[zuständiger Verkäufer] = "ohne Verkäufer"
WHERE (((Kundendaten.zv)<>"ohne Verkäufer") AND ((Kundendaten.[Kunden-Nr]) In (select [Kunden-Nr] FROM Kontakte WHERE nz([Erstellungs-Datum],date()) < date()-120)))
damit werden nur die DS geändert, die älter als 120 Tage sind, ohne die, in denen im Datumsfeld NULL steht, in der folgenden sind auch die DS mit NULL im Datum berücksichtigt:
UPDATE Kundendaten SET Kundendaten.[zuständiger Verkäufer] = "ohne Verkäufer"
WHERE (((Kundendaten.zv)<>"ohne Verkäufer") AND ((Kundendaten.[Kunden-Nr]) In (select [Kunden-Nr] FROM Kontakte WHERE nz([Erstellungs-Datum],0) < date()-120)))
In beiden Fällen werden die, die bereits "ohne Verkäufer" eingetragen hatten nicht mehr berücksichtigt. Auf den Felder n [Kunden-Nr], [zuständiger Verkäufer] und [Erstellungs-Datum], sollte auf jedenfall ein Index liegen.
Vielleicht hilfts.
Gruß
Ralf
Antwort 6 von feldfunktion
hallo ralf,
danke für die hilfe, ich probier es gleich aus. meine datenbank ist übrigens aufgeteilt, das be läuft auf dem hauptserver, das fe auf den clients.es ist übrigens meine erste und ich bin ganz glücklich, wie gut sie funktioniert.
hast du vielleicht erfahrung damit, wie sie sich verhält, wenn mehrere user über einen terminalserver darauf zugreifen (so ungefähr 12)? wir kriegen aussenbüros in mallorca und südfrankreich, die sollen hier angebunden werden. ich hab gehört, dass access dann viel zu langsam wird.
gruss, feldfunktion
danke für die hilfe, ich probier es gleich aus. meine datenbank ist übrigens aufgeteilt, das be läuft auf dem hauptserver, das fe auf den clients.es ist übrigens meine erste und ich bin ganz glücklich, wie gut sie funktioniert.
hast du vielleicht erfahrung damit, wie sie sich verhält, wenn mehrere user über einen terminalserver darauf zugreifen (so ungefähr 12)? wir kriegen aussenbüros in mallorca und südfrankreich, die sollen hier angebunden werden. ich hab gehört, dass access dann viel zu langsam wird.
gruss, feldfunktion
Antwort 7 von feldfunktion
hallo ralf,
in dem sql-code ist ein syntaxfehler drin, nach dem "IN", leider bin ich nicht so fit , dass ich den Fehler finden kann....
in dem sql-code ist ein syntaxfehler drin, nach dem "IN", leider bin ich nicht so fit , dass ich den Fehler finden kann....
Antwort 8 von Hinki27
Hallo feldfunktion,
sorry, ich habe bei der Übernahme des SQL-Statements was vergessen umzusetzen (ich habe in meiner Tabelle statt "zuständiger Verkäufer" "zv" verwendet (ich hasse Leerzeichen und Umlaute in Feldnamen, das macht nur Ärger bei der Übernahme in andere DBs).
Das Statement hier in korrekter Schreibweise:
UPDATE Kundendaten SET Kundendaten.[zuständiger Verkäufer] = "ohne Verkäufer"
WHERE (((Kundendaten.[zuständiger Verkäufer])<>"ohne Verkäufer") AND ((Kundendaten.[Kunden-Nr]) In (select [Kunden-Nr] FROM Kontakte WHERE nz([Erstellungs-Datum],date()) < date()-120)))
Entsprechnd musst du das zweite Statement umsetzen.
Ich habe vor ca. 5 Jahren mal Tests mit Terminalservern und Access gemacht, ist wirklich nicht so der Hammer in Sachen Geschwindigkeit. Ich habe damals mit ISDN-Verbindungen gearbeitet.
Gruß
Ralf
sorry, ich habe bei der Übernahme des SQL-Statements was vergessen umzusetzen (ich habe in meiner Tabelle statt "zuständiger Verkäufer" "zv" verwendet (ich hasse Leerzeichen und Umlaute in Feldnamen, das macht nur Ärger bei der Übernahme in andere DBs).
Das Statement hier in korrekter Schreibweise:
UPDATE Kundendaten SET Kundendaten.[zuständiger Verkäufer] = "ohne Verkäufer"
WHERE (((Kundendaten.[zuständiger Verkäufer])<>"ohne Verkäufer") AND ((Kundendaten.[Kunden-Nr]) In (select [Kunden-Nr] FROM Kontakte WHERE nz([Erstellungs-Datum],date()) < date()-120)))
Entsprechnd musst du das zweite Statement umsetzen.
Ich habe vor ca. 5 Jahren mal Tests mit Terminalservern und Access gemacht, ist wirklich nicht so der Hammer in Sachen Geschwindigkeit. Ich habe damals mit ISDN-Verbindungen gearbeitet.
Gruß
Ralf
Antwort 9 von feldfunktion
hallo ralf,
leider liefert die abfrage nicht das gewünschte ergebnis. wenn ich daraus eine auswahlabfrage mache, bekomme ich immer noch die datensätze bis zum 12.1.2005 angezeigt, bei meiner variante zeigt er sie nur bis 20.9.04 an. das mit dem zv habe ich schon verstanden, aber was ist nz? das habe ich bei diversen postings gesehen, aber ich kenne das nicht.
vielen dank auf jeden fall für deine mühe.
leider liefert die abfrage nicht das gewünschte ergebnis. wenn ich daraus eine auswahlabfrage mache, bekomme ich immer noch die datensätze bis zum 12.1.2005 angezeigt, bei meiner variante zeigt er sie nur bis 20.9.04 an. das mit dem zv habe ich schon verstanden, aber was ist nz? das habe ich bei diversen postings gesehen, aber ich kenne das nicht.
vielen dank auf jeden fall für deine mühe.
Antwort 10 von Hinki27
Hallo feldfunktion,
nz ist eine Abkürzung für "nullZero" oder so ähnlich. Diese Funktion wandelt NULL-Werte um in einen Defaultwert, der entweder als zweiter Parameter (variant) angegeben ist, oder von dem Datentyp abgeleitet wird, wenn der zweite Parameter fehlt.
Gruß
Ralf
nz ist eine Abkürzung für "nullZero" oder so ähnlich. Diese Funktion wandelt NULL-Werte um in einen Defaultwert, der entweder als zweiter Parameter (variant) angegeben ist, oder von dem Datentyp abgeleitet wird, wenn der zweite Parameter fehlt.
Gruß
Ralf