Ankündigung

Einklappen
Keine Ankündigung bisher.

SQL Abfrage mit div. Parametern klappt nicht

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • SQL Abfrage mit div. Parametern klappt nicht


    Hallo,

    habe schon geegoogelt, finde aber nichts was fruchtet. Die Abfrage liefert Ergebnisse, allerdings: "last_edit" ist ebenso ein Timestamp wie "$timestamp2", diese werden aber bei der Abfrage ignoriert. Habe div. Klammernvariationen versucht, funktionieren alle gleich im Bezug auf "last-edit" - nicht. Wie geht das?


    PHP-Code:
    WHERE
        
    (
        (
    last_edit '$timestamp2')
        and 
    provision NOT LIKE '%incl%')
        and (
    provision NOT LIKE '%Nein%')
        and (
    provision NOT LIKE '%mwst_ok%')
        and (
    provision LIKE '%zzgl%'
        
    or provision LIKE '%zuz%'
        
    or provision_txt LIKE '%zzgl%'
        
    or provision_txt LIKE '%zuz%')
        or (
    provision NOT LIKE '%inkl%'
        
    )
        
    ORDER BY anlagedatum DESC
    SQL

    1000 Dank für Hilfestellung vorab!

  • #2
    Bitte Tabellenstruktur mit Testdaten als SQL-Code mitliefern. Außerdem bitte keinen PHP-Code posten, sondern reinen SQL-Code.

    Kommentar


    • #3
      Mir ist nicht ganz klar, was gepostet werden soll, ich versuche es. Diese Abfrage

      PHP-Code:
      SELECT *
      FROM `anzeigen`
      WHERE (
      (  
      last_edit '$timestamp2' )
      AND 
      provision NOT LIKE '%incl%'
      )
      AND (
      provision NOT LIKE '%Nein%'
      )
      AND (
      provision NOT LIKE '%mwst_ok%'
      )
      AND (
      provision LIKE '%zzgl%'
      OR provision LIKE '%zuz%'
      OR provision_txt LIKE '%zzgl%'
      OR provision_txt LIKE '%zuz%'
      )
      OR (
      provision NOT LIKE '%inkl%'
      )
      ORDER BY anlagedatum DESC 
      in PHPmyAdmin ausgeführt liefert hunderte Treffer, funktioniert also grundsätzlich, bringt aber auch veraltete zuvor. Die Spalten sind

      last_edit = varbinary500 = z.B. "1530741600" ($timestamp wird abgespeichert, hier = 05.07.2018)

      PHP-Code:
      $timestamp time();
      $timestamp2 $timestamp-259200
      "last_edit" ist also der Timestamp "gerade jetzt" (zur Ausführungszeit) und der "$timestamp2" dem identisch minus 3 Tage. Ein Datum in 2018 sollte somit durch SQL heute aussortiert werden, was nicht passiert.

      provision = varbinary800 = z.B. "2%" oder auch "Nein" oder "Ja" oder "3,5% von Preis" >> ein kurzer Text mit meist wenger als 20 Zeichen

      provision_txt = varbinary5000 = z.B. "2% inkl. MwSt. vom Angebotspreis" >> ein etwas längerer Text mit im Schnitt 15 bis 200 Zeichen

      Ist es so klarer?

      LG

      Joy

      Kommentar


      • #4
        In Mysql auf Export klicken.
        Dann denn SQL Dump hier als Text rein kopieren. Nutze dazu die Code Tags bevor du den Code rein kopierst.

        Kommentar


        • #5
          Warum speicherst du den Timestamp als Zahl ab? Verwende doch den TIMESTAMP-Datentyp von MySQL.

          Kommentar


          • #6
            Was soll "diese werden aber bei der Abfrage ignoriert" bedeuten?

            Dir ist klar, das du OR-Verknüpfungen verwendest und welche Auswirkungen das auf (d)ein Ergebnis hat?
            Es ist völlig egal, ob andere Filter zutreffen, sofern ein OR-verknüpfter Filter greift. Und die sehen mehr als unglücklich aus (NOT LIKE '%..%' ist ein "gefährliches" Kriterium, weil sowas potentiell auf massig Datensätze zutreffen kann)

            Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

            Kommentar


            • #7
              Zitat von lstegelitz Beitrag anzeigen
              Was soll "diese werden aber bei der Abfrage ignoriert" bedeuten?

              Dir ist klar, das du OR-Verknüpfungen verwendest und welche Auswirkungen das auf (d)ein Ergebnis hat?
              Es ist völlig egal, ob andere Filter zutreffen, sofern ein OR-verknüpfter Filter greift. Und die sehen mehr als unglücklich aus (NOT LIKE '%..%' ist ein "gefährliches" Kriterium, weil sowas potentiell auf massig Datensätze zutreffen kann)
              Hallo Joy
              Eigentlich wollte ich hier nicht mehr posten, aber du kannst ja nichts dafür, daß dieses Forum ist, wie es ist. Istegelitz war ganz nah dran, ich frage mich, warum er es nicht konsequent zuende geführt hat.

              Also, folgende Schritte/Bemerkungen:
              1. In Deinem SQL-Statement entfernst du bitte die vorletzte schließende und die letzte öffnende Klammer, der Code sieht dann so aus:
                Code:
                SELECT *
                	FROM `anzeigen`
                	WHERE (
                	(  last_edit > '$timestamp2' )
                	AND provision NOT LIKE '%incl%'
                	)
                	AND (
                	provision NOT LIKE '%Nein%'
                	)
                	AND (
                	provision NOT LIKE '%mwst_ok%'
                	)
                	AND (
                	provision LIKE '%zzgl%'
                	OR provision LIKE '%zuz%'
                	OR provision_txt LIKE '%zzgl%'
                	OR provision_txt LIKE '%zuz%'
                
                	OR 
                	provision NOT LIKE '%inkl%'
                	)
                	ORDER BY anlagedatum DESC
              2. Dadurch, daß du einen durch die AND-Operatoren "unsichtbar geklammerten" Ausdruck links von
                Code:
                OR ( 
                	provision NOT LIKE '%inkl%'
                	)
                hattest, wurden - wie Istegelitz bereits schrieb - alle Datensätze, die letzterer Bedingung genügten in die Auswahl übernommen, also möglicherweise alle. Die Datensätze, die dieser Bedingung nicht genügten, wurden dann in die Auswahl übernommen, wenn sie dem gesamten komplexen Ausdruck aus 8 Bedingungen, die du da gebastelt hast, genügten. Je nachdem, wie viele Datensätze mit dem unerwünschten "inkl" existieren und ob überhaupt, ist diese zusammengesetzte Bedingung mehr oder weniger irrelevant geworden, was sicherlich nicht deine Absicht war.
              3. Ich kann dir nicht garantieren, daß die Abfrage dann das gewünschte Ergebnis erbringt, aber dieser Fehler war mit 99%iger Wahrscheinlichkeit die Ursache für die von dir geschilderten Probleme. U.a. war deine Zeitraum-Bedingung nicht die Ursache, was gleichwohl nicht ausschließt, daß sie falsch formuliert war (m.E. darf $timestamp2 dort kein String sein).
              4. Soweit, zunächst.
                Kommen wir zu den weiteren Fehlern:
                Vorweg: Ich weiß nicht, für wen du diese Sache machst und welchen beruflichen Hintergrund du mitbringst, aber dein Vorgehen ist absolut unprofessionell und man kann nur sagen: So wird das nichts.
              5. Zum Vorgehen: Wenn man eine Entwicklung macht, die mehrere Schwachstellen hat wie hier, wird das ganze zunächst in seine Bestandteile zerlegt. D.h. du hast ein Problem mit dem Timestamp - also machst du erstmal eine ähnliche Abfrage, die aber wesentlich einfacher ist und als einzige Schwierigkeit den Timestamp enthält. Usw.
              6. Zum Timestamp hast du eine Menge Hinweise bekommen, ich würde ihn mit den vorhandenen Datums- und Zeitfunktionen behandeln, die MySQL und PHP enthalten.
              7. Wie gesagt: Zu 99% ist das Problem mit der Entfernung der Klammern behoben, aber es können noch andere Fehler in deiner Konstruktion sein. Beschäftigen wir uns also damit: Offensichtlich willst du da alle möglichen Konstellationen der Freitext-Eingabe in den Feldern provision und provision_txt auffangen.
                So macht man sowas aber nicht. Entweder, du listest alle Eventual-Fälle von Konditionen und ihrer Kombinationen, die relevant sind auf und läßt den User in dem entsprechenden Eingabeformular aus diesen Einträgen wählen oder du siehst dort Radiobuttons/Checkboxen für die verschiedenen Optionen vor. Die gehören dann ggfs. in eine Extra-Tabelle. Darüber müsste man dann nochmal reden.

              Kommentar


              • #8
                @Alf2016: Vielen Dank für die Hilfestellung sowie konstruktive Kritik. Die Abfrage funktioniert so, der Timestamp war tatsächlich nicht das Problem, eigentlich ja uch offensichtlich. Ich hatte mich in diesen verbissen und so den Rest aus dem Blick verloren, wirklich sehr unprofessionell, eigentlich teste ich dann die Abfragen durch. Hier erschien mir der Fehler aber woanders, schon weicht man ab, nicht gut. Ich habe mir PHP und SQL nur etwas nebenbei angeeignet so wie ich es brauchte, nicht aber konsequent gelernt und setze es nur für eigene Projekte ein. Diese sind Hobby bzw. erleichtern mir den Job, sind aber nicht lebensnotwendig. Hier sollen Inserate von Portalen untersucht werden, weswegen ich auch keinen Einfluss auf die Formularfelder habe, die hier freie Textfelder sind.

                @Isteglitz: Vielen Dank und ja, grundsätzlich ist mir die Bedeutung von OR bekannt. Mein Denkfehler war, wegen der alten Einträge, den Timestamp als Fehler zu vermuten und diesen nicht einzeln zu testen. Unprofessionell trifft es ...

                @alle: Vielen Dank für die sonstige Hilfe!

                Kommentar


                • #9
                  Zitat von Joy Beitrag anzeigen
                  @Alf2016: Vielen Dank...
                  @Isteglitz: Vielen Dank und ja, grundsätzlich... Unprofessionell trifft es ...

                  @alle: Vielen Dank für die sonstige Hilfe!

                  Dein Dank ist mir eine Spur zu überschwenglich. Ich glaube, hier wären alle froh, wenn du deinen Dank und die Anerkennung der Hilfestellung z.B. dadurch zum Ausdruck bringen würdest, daß du die Möglichkeit, DB-Dumps zu schicken, benutzt...

                  Kommentar

                  Lädt...
                  X