Aktualisierungsabfrage

[Artois]

Habe leider eine neueres Access, ca. 2008. Da sieht allerhand anders aus als früher und deshalb meine Frage:

Ich habe eine Aktualisierungsabfrage erstellt, doch beim Klick auf das ! passiert gar nichts!! Auch der KLick auf das Icon des Abfrageentwurfs bewirkt nichts!

Wie führe ich die Abfrage nun aus?

Herzlichen Dank im Voraus, Artois

[DF6GL]

Hallo,

Wie sicher bist Du, dass die Akt-Abfrage nicht ausgeführt wird?  Vielleicht findet sie nichts zum Aktualisieren, weil

-- falsche Kriterien
-- falsche Werte
-- falsche Namen/Datentypen

verwendet werden.

Zeige mal den SQL-String der Abfrage...

[Artois]

Das sieht ungefähr so aus:


UPDATE a_tontitel
LEFT JOIN a_text ON a_tontitel.fs_text = a_text.ps_text
SET a_tontitel.fs_text = 3333
WHERE fs_text Is Not Null AND textincipit1 Not Like "*";

[DF6GL]

Hallo,


soll das eine einmalige Korrektur von Datensatz-Zuordnungen von 1:n-Tabellen sein?

Nur für solche Reparatur-Zwecke ist das Setzen von Schlüsselfeldern auf diese Art geeignet.


Zudem:

Welchen Datentyp hat "fs_text" in der Tabelle?
Sicher, dass genau solche DS mit diesem Kriterium "  fs_text Is Not Null "  aktualisiert werden sollen??
Was soll .." Not Like "*"..." bezwecken?

[Artois]

DAs erkläre ich gern. Not like "*" bedeutet, daß nur diejenigen Datensätze bearbeitet werden sollen, für die gilt, daß in dem entsprechenden Feld der sekundären Tabelle kein Text eingetragen ist.

"Not null" ist selbstverständlich, denn ich will nur diejenigen Felder ändern, bei denen etwas eingetragen ist. Der fs_text hat wie alle meine Fremdchlüssel das Format "long integer".

Die Abfrage an sich ist also lupenrein. (wie ich meine) 

[DF6GL]

Hallo,



WHERE fs_text Is Not Null AND textincipit1 Is Null


ist lupenreiner...

[Artois]

Aus uralter Gewohnheit teste ich Text und Memo-Felder immer mit dem * ab ... Ich bitte um Entschuldigung.

[DF6GL]

Hallo,

es braucht doch  keine Entschuldigung   

[ebs17]

Rückfrage: Was fällt in die Definition "lupenrein"?

Code [Auswählen] Erweitern

WHERE fs_text Is Not Null
Das NOT im Kriterium verhindert die Nutzung des Index des Schlüsselfeldes und ist daher bezüglich Performance ein grober Fehler.

Ein Longfeld könnte man ersatzweise so abfragen:

Code [Auswählen] Erweitern

WHERE (fs_text > 0 OR fs_Text <= 0)

Hat man typischerweise nur positive Schlüssel (Autowert im Rahmen des Wertebereiches von ca. 2,14 Mrd.), kann man auf den OR-Part verzichten. Aber selbst wenn nicht: Der "Aufwand" der zehn zusätzlichen Zeichen macht sich bezahlt.

MfGA
ebs

[Artois]

Hä?

Da muß ich protestieren. Abgesehen dacvon, daß es völlig sinnlos ist nach negativen Werten abzufreagen scheint mir die Formulierung

Is not null

völlig regelgerecht zu sein. Formuliere es seit Jahrzehnten ohne die geringsten Probleme in jeder Umgebung völlig erfolgreich so und so steht's wohl auch in den Referenzen. HAbe auch schon zig UPdates so formuliert, aht immer exakt und bestens geklappt! 

[DF6GL]

Hallo,


mein "lupenreiner" (nicht lupenreinster     ) Vorschlag bezog sich auf das blau markierte Kriterium.....

ebs hat  völlig Recht, wenn die Anwendung auf ein  Long -Feld ( in der "Regel" gehören dazu auch die Schlüsselfelder) und die Verwendung des  "NOT" betrachtet wird.

Negative Werte mit dieser Methode abzufragen ist aber ein MUSS, weil bei einem Long-Datentyp nicht ausgeschlossen werden kann, dass negative Werte auftauchen  (z. B. bei einem (Schlüssel-) Wert-Feld mit Einstellung auf "zufälligen" Autowert).



Der Hinweis zielt m. E. eher auf die Optimierung der Performance als auf die logische Funktionalität hin.

[ebs17]

Der Hinweis zielt m. E. eher auf die Optimierung der Performance als auf die logische Funktionalität hin.

Genauer: Eine gute Abfrage (um einen anderen Begriff als lupenrein, nach dessen Definition ich gefragt hatte, zu verwenden) beinhaltet für mich Funktionalität und hohes Performancepotential.

Das kollidiert auch nicht mit persönlichen Erfahrungen:

Formuliere es seit Jahrzehnten ohne die geringsten Probleme in jeder Umgebung völlig erfolgreich so

Verwendete Umgebungen und Erwartungen an benötigte Zeiten für Abfragen können sehr unterschiedlich sein.

Ein schönes Beispiel für den möglichen Unterschied zwischen Nichtnutzung und Nutzung eines Index:
Performance total mies

[Artois]

Bei jeder Abfrage mit NOT NULL ist die Performance optimal. Mir ging es aber eher um da UPdate!!