Du befindest Dich im Archiv vom ABAKUS Online Marketing Forum. Hier kannst Du Dich für das Forum mit den aktuellen Beiträgen registrieren.

SELECT Statement spinnt? MS Access

Ajax, Hijax, Microformats, RDF, Markup, HTML, PHP, CSS, MySQL, htaccess, robots.txt, CGI, Java, Javascript usw.
e-fee
PostRank 10
PostRank 10
Beiträge: 3893
Registriert: 08.05.2007, 12:53

Beitrag von e-fee » 25.08.2010, 15:46

Stehe vor einem Rätsel:

Code: Alles auswählen

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?

Anzeige von ABAKUS

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

Anonymous

Beitrag von Anonymous » 25.08.2010, 15:51

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

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

profo
PostRank 9
PostRank 9
Beiträge: 1703
Registriert: 18.01.2007, 18:51

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...

Anzeige von ABAKUS

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.


DanielS
PostRank 9
PostRank 9
Beiträge: 1179
Registriert: 03.08.2008, 08:45

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

e-fee
PostRank 10
PostRank 10
Beiträge: 3893
Registriert: 08.05.2007, 12:53

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? :roll:
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! :roll:
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!

e-fee
PostRank 10
PostRank 10
Beiträge: 3893
Registriert: 08.05.2007, 12:53

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 ...

Beloe007
PostRank 10
PostRank 10
Beiträge: 2928
Registriert: 05.03.2009, 10:31

Beitrag von Beloe007 » 25.08.2010, 17:22

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

Anonymous

Beitrag von Anonymous » 25.08.2010, 17:23

Beloe007 hat geschrieben:SELECT * FROM tabelle WHERE feld NOT LIKE 'meinstring';
LIKE ist böse.... :-?

e-fee
PostRank 10
PostRank 10
Beiträge: 3893
Registriert: 08.05.2007, 12:53

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!!!).

Beloe007
PostRank 10
PostRank 10
Beiträge: 2928
Registriert: 05.03.2009, 10:31

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 |
+--------------------------------------+

e-fee
PostRank 10
PostRank 10
Beiträge: 3893
Registriert: 08.05.2007, 12:53

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!)

Beloe007
PostRank 10
PostRank 10
Beiträge: 2928
Registriert: 05.03.2009, 10:31

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.

e-fee
PostRank 10
PostRank 10
Beiträge: 3893
Registriert: 08.05.2007, 12:53

Beitrag von e-fee » 25.08.2010, 19:04

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

Beloe007
PostRank 10
PostRank 10
Beiträge: 2928
Registriert: 05.03.2009, 10:31

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 :)

Anonymous

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...

Antworten
  • Vergleichbare Themen
    Antworten
    Zugriffe
    Letzter Beitrag