SELECT Statement spinnt? MS Access

Beitrag von **Beloe007** » 25.08.2010, 20:48

Einer
https://stackoverflow.com/questions/543 ... 40#2336940
und ein anderer
https://stackoverflow.com/questions/543 ... 593#543593

und noch einer:

This answer is terrible. LIKE and '=' are completely distinct operators, but just happen to behave similarly in some small subset of cases. For the sake of posterity, please read the rest of the replies here, or at least google for "mysql like" before you commit this to memory. – mehaase Jun 2 at 10:41

...aber wird mir jetzt zu viel.

Ich habe meines gesagt, ich habe davon keine Ahnung... weiß nur was mir mal jemand mit viel Ahnung gesagt hat.

Ich muss hier keine Quellen suchen, habe kein Problem, ich muss mir das eh mal abgewöhnen kostet zu viel Zeit die guten Beiträge zwischen dem ganzen veralteten und weiterverbreiteten Müll im Internet zu finden.

Und auch MySQL hat sich weiterentwickelt

von **Anzeige von ABAKUS** »

Content Erstellung von ABAKUS Internet Marketing
Ihre Vorteile:

einzigartige Texte
suchmaschinenoptimierte Inhalte
eine sinnvolle Content-Strategie
Beratung und Umsetzung

Jetzt anfragen: 0511 / 300325-0

Beitrag von **Beloe007** » 25.08.2010, 21:02

PS damit zumindest das Wesentliche für den Thread gequotet ist:

EQUALS compares two pieces of data byte by byte. This means that equivalent strings in different encodings may not be equal, even though they look the same to the eye.

LIKE compares strings, and it takes into account the encoding of each string so as not to be fooled by different encodings of the same content.

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

Beloe007 hat geschrieben:PS damit zumindest das Wesentliche für den Thread gequotet ist:

hmm... nur das genau das nun hier nix zur Sache tut... weil ja schon gesagt wurde das es keine Sonderzeichen gibt die je nach encoding anders sein könnten...

und bezüglich der performance hattest du ja bereits selber einen Link mit Vergleichen gepostet: https://myitforum.com/cs2/blogs/jnelson ... 08354.aspx

und wenn du dir dort die Unterschiede zwischen = und LIKE bei einem Wort ohne wildcards anschaust ist das schon ein netter Unterschied...

mit = sind es 0,0065704 und mit LIKE eben 0,0083908

also mit LIKE dauert es fast 28% länger...

von **Anzeige von ABAKUS** »

SEO Consulting bei ABAKUS Internet Marketing
Erfahrung seit 2002

persönliche Betreuung
individuelle Beratung
kompetente Umsetzung

Jetzt anfragen: 0511 / 300325-0.

Beitrag von **sx06050** » 25.08.2010, 21:37

Folgendes sollte funktionieren

SELECT *
FROM testtabelle
WHERE (((testtabelle.[testfeld])<>'mein' Or (testtabelle.[testfeld]) Is Null)) OR (((testtabelle.[testfeld])=" "));

Das demenstprechende testtabelle etc. natürlich dann noch austauschen

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

btw. Performance und Konsistenz usw... ist bei Oracle äußerst wichtig, gerade wenn man für mehrere hundert Millionen Datensätze X abfragen gleichzeitig managen muss... auch wenn da die Antwort nicht in Millisekunden da sein muss

net(t)worker hat geschrieben:und bezüglich der performance hattest du ja bereits selber einen Link mit Vergleichen gepostet: https://myitforum.com/cs2/blogs/jnelson ... 08354.aspx

Das war 2007, was aktuelleres habe ich leider nicht gefunden.

Will auch nicht abstreiten das es nicht mehr so ist, aber verneinen würde ich es auch nicht. Zumindest wenn man keinen Index anlegt.

weil ja schon gesagt wurde das es keine Sonderzeichen gibt die je nach encoding anders sein könnten...

->

e-fee hat geschrieben:Wenn ich die Bedingung in Klammern gesetzt verneine, bekomme ich korrekt nur die Datensätze mit meinstring.

Das ist der springende Punkt, der mich zu der Antwort gebracht hat... die ich im Nachhinein, wegen dem Zeitaufwand, bedauere.

Beitrag von **nerd** » 26.08.2010, 07:23

e-fee hat geschrieben:Gibt da so ein Stichwort, das nennt sich Performance ...

Und weil du performance brauchst faellt deine wahl auf MS Access?

prinzipiell benutzt man <> fuer numerische vergleiche, und LIKE/NOT LIKE fuer stringvergleiche (muss man nicht machen ; ist aber guter stil). performanceprobleme bekommst du erst wenn deine suche mit einer wildcard beginnt (... WHERE field LIKE '%mystring%' ...) weil dann auch ein index nutzlos ist und wirklich jedes feld von anfang bis ende verglichen werden muss.

ansonsten: welchen zeichensatz und feldtypen benutzt du fuer dein fragliches feld?

Beitrag von **Beloe007** » 26.08.2010, 08:58

Puh, jetzt bin ich erleichtert, Danke!

btw. @sx06050
Sehr Leistungsstark sieht das nicht aus im Vergleich zu NOT LIKE

Beitrag von **sx06050** » 26.08.2010, 11:08

Ok, um die Leistungsstärke ging´s mir ja ned.
Es sollte in der Ursprungsfrage ja lediglich funktionieren, dass alle Datensätze kommen.
Hab´s einfach kurz ins Access eingegeben und dann die SQL-Ansicht hier gepostet.

Beitrag von **e-fee** » 26.08.2010, 16:20

DanielS hat geschrieben: SELECT * FROM tabelle WHERE feld <> 'meinstring' or feld IS NULL

Jo, das war's, das hat geholfen!
In der Tabelle gab es aus welchen Gründen auch immer zwei Arten von leeren Feldern innerhalb dieser Spalte. Die einen wurden ja auch schon vorher angezeigt, die anderen nicht.
Letztere waren dann NULL. Erstere nicht.

Ansonsten noch zu Access und Performance: ICH hab mir NICHT ausgesucht, damit zu arbeiten!

Beitrag von **DanielS** » 26.08.2010, 16:32

e-fee hat geschrieben:
DanielS hat geschrieben: SELECT * FROM tabelle WHERE feld <> 'meinstring' or feld IS NULL
Jo, das war's, das hat geholfen!

Freut mich. Oder um das in diesem Thread am meisten gefallenen Wort zu benutzen: I LIKE it

Beitrag von **Anonymous** » 26.08.2010, 16:34

hmm... NULL ist nicht <> 'meinstring'?

komisches winzigweich gedöns...

Beitrag von **DanielS** » 26.08.2010, 16:38

net(t)worker hat geschrieben:hmm... NULL ist nicht <> 'meinstring'?

komisches winzigweich gedöns...

Ich hätte jetzt gesagt, das hat nix mit winzigweich zu tun, weil es in MS SQL Server auch so ist, aber das ist ja auch winzigweich-zeug

WHERE bla = '' liefert auch keine Zeilen mit NULL-Werten.

Beitrag von **Anonymous** » 26.08.2010, 16:44

DanielS hat geschrieben:WHERE bla = '' liefert auch keine Zeilen mit NULL-Werten.

gut, das NULL und '' Unterschiedliche Werte sind kann ich noch ein wenig nachvollziehen.... aber beides ist doch ganz eindeutig <> 'meinstring'...

Beitrag von **sx06050** » 26.08.2010, 17:14

ist so: zwischen Null, Nix und Leer ist nen Unterschied.

Beitrag von **e-fee** » 26.08.2010, 17:20

DanielS hat geschrieben:
e-fee hat geschrieben:
DanielS hat geschrieben: SELECT * FROM tabelle WHERE feld <> 'meinstring' or feld IS NULL
Jo, das war's, das hat geholfen!
Freut mich. Oder um das in diesem Thread am meisten gefallenen Wort zu benutzen: I LIKE it

Wir sollten mal schauen, wo der Fred jetzt zu LIKE rankt - zumindest bei den deutschsprachigen Ergebnissen!