Neu SQL Fehler - Woher stammt diese Abfrage

[hvsdha]

Guten Tag, wir haben in unsere Shop Log unten stehende SQL-Fehler entdeckt, können aber nicht ganz nachvollziehen, woher es stammt. Ist es ein Abfrage von einer Plug-In oder JTL-Shop interne Funktion Aufruf?

Error executing query SELECT  SUM(ssMerkmal.anz0) AS anz0, SUM(ssMerkmal.anz1) AS anz1, SUM(ssMerkmal.anz2) AS anz2, SUM(ssMerkmal.anz3) AS anz3 FROM (SELECT COUNT(DISTINCT IF( < 2500, tartikel.kArtikel, NULL)) AS anz0, COUNT(DISTINCT IF( < 5000, tartikel.kArtikel, NULL)) AS anz1, COUNT(DISTINCT IF( < 7500, tartikel.kArtikel, NULL)) AS anz2, COUNT(DISTINCT IF( < 10000, tartikel.kArtikel, NULL)) AS anz3
            FROM tartikel LEFT JOIN tartikelkategorierabatt ON tartikelkategorierabatt.kKundengruppe = 1 AND tartikelkategorierabatt.kArtikel = tartikel.kArtikel
LEFT JOIN tartikelsonderpreis ON tartikelsonderpreis.kArtikel = tartikel.kArtikel
                        AND tartikelsonderpreis.cAktiv = Y
                        AND tartikelsonderpreis.dStart = CURDATE())
LEFT JOIN tsonderpreise ON tartikelsonderpreis.kArtikelSonderpreis = tsonderpreise.kArtikelSonderpreis
                        AND tsonderpreise.kKundengruppe = 1

#join1 from JTLFilterItemsPriceRange::getOptions
JOIN (tpreis
#subjoin for tpreis table
JOIN tpreisdetail ON tpreisdetail.kPreis = tpreis.kPreis AND tpreisdetail.nAnzahlAb = 0) ON tpreis.kArtikel = tartikel.kArtikel
                    AND tpreis.kKundengruppe = 1

#join2 from JTLFilterItemsPriceRange::getOptions
LEFT JOIN tartikelsichtbarkeit ON tartikel.kArtikel = tartikelsichtbarkeit.kArtikel
                        AND tartikelsichtbarkeit.kKundengruppe = 1

 WHERE tartikelsichtbarkeit.kArtikel IS NULL AND tartikel.kVaterArtikel = 0 AND  (tartikel.cLagerBeachten != Y
                    OR tartikel.fLagerbestand > 0
                    OR (tartikel.cLagerVariation = Y
                        AND (
                            SELECT MAX(teigenschaftwert.fLagerbestand)
                            FROM teigenschaft
                            INNER JOIN teigenschaftwert ON teigenschaftwert.kEigenschaft = teigenschaft.kEigenschaft
                            WHERE teigenschaft.kArtikel = tartikel.kArtikel
                        ) > 0
                    ))
#default group by
GROUP BY tartikel.kArtikel

#limit sql
ORDER BY tartikel.dErstellt DESC, tartikel.cName ) AS ssMerkmal
SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near < 2500, tartikel.kArtikel, NULL)) AS anz0, COUNT(DISTINCT IF( < 5000, tartike... at line 1

 

[wo0dle]

Welche Shop Version hast du? Bei uns ist es der gleiche Fehler in der Version 5.3.1.
Wir warten auf Version 5.3.2. dort sollen einige Bugs behoben werden, die es derzeit mit der Shop Version 5.3.1 gibt. Gibt es schon einen Termin wann die Version kommt?

https://issues.jtl-software.de/issues?project=shop&version=5.3.2

 

[hvsdha]

Wir benutzen noch Shop Version 5.2.4
Das Fehler haben wir, nachdem wir Doofinder auf aktuelle Version upgedated haben gesehen. Haben weiterhin extreme Probleme mit Doofinder.

 

[ongnamo]

auch wir haben extreme Probleme mit doofinder, seit wir letzte Woche ein Update gemacht haben. Im Indexierungskreis hat man jetzt graue Segmente für nicht erfasste Produkte. Außerdem werden bei der Suche nach Artikelnummer keine oder falsche Ergebnisse ausgespuckt. Angeblich ist man doofinder-seitig bereits mit Webstollen in Kontakt, doch nach Rückfrage bei Webstollen bekommen wir auch von dort keine Antwort. Läuft echt super mit dieser Suche 🙁

 

[css-umsetzung]

Laut support von Doofinder sollte man lieber eine ältere Version verwenden.
Habe selbst nicht mit denen gesprochen, dass wurde mir von einem Kunden so gesagt der auch Probleme hat und die am Telefon hatte.

 

[ongnamo]

temporär hat nun der Support von df eine ältere Version zurückgespielt, weil sie das aktuelle Problem auf die Schnelle nicht in den Griff kriegen.

 

[Michael2023]

Auch ich finde in unserem Shop sporadisch exakt diese Fehlermeldung (siehe oben Beitrag von hsdva). Meiner Meinung nach beinhaltet die letzte Zeile der SQL-Abfrage einen Fehler:
Im Befehl: ORDER BY tartikel.dErstellt DESC, tartikel.cName ) AS ssMerkmal fehlt die Klammer ( nach ORDER BY. Richtigerweise sollte der Befehl lauten:
ORDER BY ( tartikel.dErstellt DESC, tartikel.cName ) AS ssMerkmal

In welcher Shop-Datei kann ich diesen Fehler ausbessern?

 

[NoOne]

Auch ich finde in unserem Shop sporadisch exakt diese Fehlermeldung (siehe oben Beitrag von hsdva). Meiner Meinung nach beinhaltet die letzte Zeile der SQL-Abfrage einen Fehler:
Im Befehl: ORDER BY tartikel.dErstellt DESC, tartikel.cName ) AS ssMerkmal fehlt die Klammer ( nach ORDER BY. Richtigerweise sollte der Befehl lauten:
ORDER BY ( tartikel.dErstellt DESC, tartikel.cName ) AS ssMerkmal

In welcher Shop-Datei kann ich diesen Fehler ausbessern?

Nein, die Abfrage ist grundsätzlich korrekt (ist die Abfrage für Preisspannen). Dort fehlen Werte. Z.B. bei "SELECT COUNT(DISTINCT IF( < 2500, tartikel.kArtikel, NULL)) AS anz0". Vor das < 2500 muss ein Wert, bzw. eigentlich eine ganze Reihe von Dingen, weil der Vergleich sonst nicht passt. Normalerweise steht da auch was. Das fällt allerdings weg, wenn in der Session kein Steuersatz verfügbar ist, und der Kunde kein Händler ist. In dem Fall hat die Preisspanne aber auch keinen Sinn, weil die korrekten Preisspannen nicht ermittelt werden können.

Meine Vermutung: Da hier in der Session was fehlt, kommt das ggf. von Crawlern/Bots, wenn für diese keine Session angelegt wird. Eventuell liegt auch eine Fehlkonfiguration der Steuersätze vor und es kommt zu einem Fall, wo für den Kunden kein Steuersatz ermittelt werden kann, sodass auch keiner in der Session gesetzt wird. Oder es ist eben ein Plugin, das sich an den Steuersätzen in der Session zu schaffen macht und die da rauslöscht.

 

[7-Lights]

Moin,
hier auch der Fehler seit gestern. Allerdings haben wir auch in einige Merkmale und Kategorien die englische Übersetzung eingetragen.

Dazu haben wir festgestellt, dass unser Google Produkt Export nicht ging, das Plugin musste ich neu installieren und schon ging es. Es kann also gut sein, dass wir die Crawler von google damit aktiviert haben, somit könnte die Vermutung von NoOne passen... gerade da die Zeiten in denen der Fehler im Log erscheint vollkommen zufällig ist.

 

[Trigoda]

Das ist schon ein Bug, der JTL Shop sollte nicht fehlerhafte Queries an die Datenbank senden, sondern das vorher "abfangen"...

Hat einer von Euch bereits ein Supportticket erstellt, damit das in den Bugtracker aufgenommen wird?

 

[NoOne]

Das ist schon ein Bug, der JTL Shop sollte nicht fehlerhafte Queries an die Datenbank senden, sondern das vorher "abfangen"...

Hat einer von Euch bereits ein Supportticket erstellt, damit das in den Bugtracker aufgenommen wird?

Das ist unverhältnismäßig großer Aufwand und Ressourcenverschwendung. Die SQL-Logik nochmal extra ein-/nachzubauen, um sämtliche Abfragen nochmal zu prüfen, bevor man sie abschickt, das wird niemand machen.

 

[Trigoda]

Das ist unverhältnismäßig großer Aufwand und Ressourcenverschwendung. Die SQL-Logik nochmal extra ein-/nachzubauen, um sämtliche Abfragen nochmal zu prüfen, bevor man sie abschickt, das wird niemand machen.

Von SQL Logik nachbauen habe ich auch nicht geredet. Und auch nicht von sämtlichen Abfragen, sondern von dieser fehlerhaften.
Wenn man unbedingt dynamische Variablen aus der Session in seine Queries schreiben muss, dann solltest man vorher schon prüfen, ob die existieren, oder mindestens einen "Default Value" festlegen 😉

 

[NoOne]

Von SQL Logik nachbauen habe ich auch nicht geredet. Und auch nicht von sämtlichen Abfragen, sondern von dieser fehlerhaften.
Wenn man unbedingt dynamische Variablen aus der Session in seine Queries schreiben muss, dann solltest man vorher schon prüfen, ob die existieren, oder mindestens einen "Default Value" festlegen 😉

Das wird geprüft. Variante A passiert, wenn ein Steuersatz in der Session ist und es kein Händler ist, Variante B ist, wenn es ein Händler ist. Das < 2500 und AS anz.$i wird danach angehangen, weil die beiden Optionen das gemeinsam haben. Kein Steuersatz & kein Händler = der Vergleichswert davor fehlt. Mit einem Default Wert gibts ggf. falsche Preisspannen. Und ob die Abfrage oder der Error "Keine Steuersätze bei Endkunde in der Session" im Log steht, macht keinen Unterschied. Und auch nicht, ob eine SQL-Abfrage, die sowieso nicht verarbeitet wird, an den SQL-Server geschickt wird. Gut, knappere Fehlernachricht würde Platz in der Log-Tabelle sparen. Und vielleicht würde es Ressourcen sparen, eine ungültige Anfrage nicht ausführen zu lassen. Die würdest du aber wieder damit verfeuern, dass du diesen ungültigen Zustand abfängst und anders verarbeitest. Wird im Endeffekt also vermutlich kaum einen Unterschied machen.