SELECT Statement spinnt? MS Access

Beitrag von **e-fee** » 25.08.2010, 15:46

Stehe vor einem Rätsel:

SELECT * FROM tabelle WHERE feld <> 'meinstring'

Feld ist Textfeld, kann leer sein,diesen String oder einen anderen enthalten. Leider bekomme ich nicht alle Datensätze zurück, die meinstring nicht enthalten. Bei Verwendung von NOT mit = dasselbe Problem, != geht nicht wegen Syntaxfehler.
Wenn ich die Bedingung in Klammern gesetzt verneine, bekomme ich korrekt nur die Datensätze mit meinstring.
In der Summe habe ich aber nur 500 + 1000 von 2500 Datensätzen, kann doch nicht sein!
Und es spielt auch keine Rolle, ob feld leer oder nicht!

Logikfehler oder Tabelle geschrottet?

von **Anzeige von ABAKUS** »

Beitrag von **Anonymous** » 25.08.2010, 15:51

und wenn du die SQL Abfrage mit einem ; am ende abschließt?

welche daten fehlen dir denn jeweils bei den einzelnen Abfragen.... also sind es z.B. die mit leerem textfeld?

Beitrag von **profo** » 25.08.2010, 16:18

Mit der Abfrage solltest Du in der Tat alle Zeilen bekommen, bei denen feld nicht exakt "meinstring" lautet. Und vergleich doch noch mal die Summen von Deiner ersten mit der negierten Abfrage, also etwa:

Code: Alles auswählen

SELECT &#40;
    &#40;SELECT COUNT&#40;*&#41; FROM tabelle&#41;
    - &#40;SELECT COUNT&#40;*&#41; FROM tabelle WHERE feld <> 'meinstring'&#41;
    - &#40;SELECT COUNT&#40;*&#41; FROM tabelle WHERE NOT &#40;feld <> 'meinstring'&#41;&#41;
&#41; as diff;

Wenn ungleich 0 ist Deine Tabelle wohl geschmolzen...

von **Anzeige von ABAKUS** »

Beitrag von **DanielS** » 25.08.2010, 16:28

e-fee hat geschrieben:Und es spielt auch keine Rolle, ob feld leer oder nicht!

Vielleicht meinst Du das damit, aber ich erwähne es trotzdem mal:

SELECT * FROM tabelle WHERE feld <> 'meinstring' or feld IS NULL

Beitrag von **e-fee** » 25.08.2010, 16:35

net(t)worker hat geschrieben:und wenn du die SQL Abfrage mit einem ; am ende abschließt?

Oh Mann, Du Nase, wenn es daran gelegen hätte, dann hätte ich in meinem Script wohl 'nen Parsing-Fehler gekriegt, aber nicht eine unvollständige Menge an Datensätzen!

Außerdem war das doch jetzt eh nur ein angepasstes Beispiel, da verzichtet man schon mal auf das Semikolon am Ende, vor allem dann, wenn man den Beitrag im Zug auf dem Handy tipselt.

Und dass es keinen Zusammenhang gibt, ob das Textfeld leer ist oder nicht, hab ich oben ja schon geschrieben.
Ebenso ist es nicht von Bedeutung, ob ich das Statement in meinem Script ausführe oder in Access direkt.
Wenn ich keine einschränkende Bedingung habe, also

Code: Alles auswählen

SELECT * FROM tabelle;

, werden auch wieder alle 2500 Datensätze angezeigt / ausgegeben.

@profo kann ich dann leider erst morgen ausprobieren, aber danke schon mal! Datenbank komprimieren und reparieren hab ich auch schon gemacht.
Sch... MS-Produkte ... manchmal!

Beitrag von **e-fee** » 25.08.2010, 16:38

DanielS hat geschrieben:
e-fee hat geschrieben:Und es spielt auch keine Rolle, ob feld leer oder nicht!
Vielleicht meinst Du das damit, aber ich erwähne es trotzdem mal:

SELECT * FROM tabelle WHERE feld <> 'meinstring' or feld IS NULL

Danke, wie gesagt scheint es ja keine Rolle zu spielen, aber ich nehme es mal als weitere Möglichkeit für morgen mit auf ...

Beitrag von **Beloe007** » 25.08.2010, 17:22

SELECT * FROM tabelle WHERE feld NOT LIKE 'meinstring';

Beitrag von **Anonymous** » 25.08.2010, 17:23

Beloe007 hat geschrieben:SELECT * FROM tabelle WHERE feld NOT LIKE 'meinstring';

LIKE ist böse....

Beitrag von **e-fee** » 25.08.2010, 17:55

net(t)worker hat geschrieben:
Beloe007 hat geschrieben:SELECT * FROM tabelle WHERE feld NOT LIKE 'meinstring';
LIKE ist böse....

Und wird hier überdies nicht benötigt.
Ich muss dazu sagen, dass die Strings jeweils aus nur einem Token (="Wort") bestehen und es derzeit auch nur eine gute Handvoll verschiedene davon gibt (was aber nicht so bleiben muss!!!).

Beitrag von **Beloe007** » 25.08.2010, 18:18

e-fee hat geschrieben:
net(t)worker hat geschrieben:
Beloe007 hat geschrieben:SELECT * FROM tabelle WHERE feld NOT LIKE 'meinstring';
LIKE ist böse....
Und wird hier überdies nicht benötigt.
Ich muss dazu sagen, dass die Strings jeweils aus nur einem Token (="Wort") bestehen und es derzeit auch nur eine gute Handvoll verschiedene davon gibt (was aber nicht so bleiben muss!!!).

Kommt wohl drauf an was in den Feldern drin steht und welche Kodierung diese haben...

https://dev.mysql.com/doc/refman/5.1/de ... tions.html

Gemäß dem SQL-Standard führt LIKE die Überprüfung auf Zeichenbasis durch, kann also Ergebnisse erzeugen, die sich von denen des Vergleichsoperators = unterscheiden:

Code: Alles auswählen

mysql> SELECT 'ä' LIKE 'ae' COLLATE latin1_german2_ci;
+-----------------------------------------+
| 'ä' LIKE 'ae' COLLATE latin1_german2_ci |
+-----------------------------------------+
|                                       0 |
+-----------------------------------------+
mysql> SELECT 'ä' = 'ae' COLLATE latin1_german2_ci;
+--------------------------------------+
| 'ä' = 'ae' COLLATE latin1_german2_ci |
+--------------------------------------+
|                                    1 |
+--------------------------------------+

Beitrag von **e-fee** » 25.08.2010, 18:24

Mmh, keine Sonderzeichen drin. Und wenn in einem Feld genau gar kein Zeichen drin steht ... klappt es bei einigen und bei anderen nicht (und nein, da sind keine Leerzeichen etc. drin!)

Beitrag von **Beloe007** » 25.08.2010, 18:50

Also ich hab von meinem Professor der DBA bei ner großen Bank war gelernt das man meistens LIKE verwenden soll... aber für den war MySQL Dreck und MS Access noch viel weniger wert. Für den gab es nur Oracle, natürlich sehr Praxisfeindlich.

Ich habe keine Ahnung wie es bei MS Access ist, MySQL benutze ich auch nur selten... also kein Plan, aber war das erste was mir in den Sinn kam.

Beitrag von **e-fee** » 25.08.2010, 19:04

Gibt da so ein Stichwort, das nennt sich Performance ...

Beitrag von **Beloe007** » 25.08.2010, 19:39

Und wo soll da der Riesen unterschied sein ohne Wildcard?

https://myitforum.com/cs2/blogs/jnelson ... 08354.aspx

Jetzt ist aber genug mach es, lass es bleiben, oder mach es anders

Beitrag von **Anonymous** » 25.08.2010, 20:05

bei einer großen DB die in oracle erstellt wurde is performance nicht das entscheidene kriterium, aber bei webdingen kommt es eben auf performance an... darum benutzt man fürs web auch mysql und nicht Oracle... eben weil mysql optimal und performent ist für webseiten...