SQL-Fehler in checkout_process.php

[Volker Strähle]

checkout_process.php:

298	    $specials_query = xtc_db_query("SELECT products_id,
299	                                           specials_quantity
300	                                      FROM ".TABLE_SPECIALS."
301	                                     WHERE products_id = '".xtc_get_prid($order->products[$i]['id'])."'
302	                                           ".SPECIALS_CONDITIONS);

Die Konstante SPECIALS_CONDITIONS kann die Spaltenangabe s.status beinhalten. Das führt zu einem Fehler.

Es sollte heißen:

298	    $specials_query = xtc_db_query("SELECT s.products_id,
299	                                           s.specials_quantity
300	                                      FROM ".TABLE_SPECIALS." s
301	                                     WHERE s.products_id = '".xtc_get_prid($order->products[$i]['id'])."'
302	                                           ".SPECIALS_CONDITIONS);

Man muss aber noch kontrolleiren ob es auch SPECIAL_CONDITIONS ohne "s." gibt.

[anonymous]

Veto.
In der checkout_process.php ist alles in Ordnung, siehe /includes/define_conditions.php

noRiddle

[Gerhard Waldemair]

in der Konstante SPECIALS_CONDITIONS kommt kein s.* vor. Nur in der Konstante SPECIALS_CONDITIONS_S

[Volker Strähle]

leider finde ich die Stelle nicht mehr, aber ich hatte eben im log den Fehler, dass s.status nicht Bestandteil der Spalten ist. (Mein Fehler das nicht zu dokumentieren)

Es stellt sich die Frage, warum man denn überhaupt 2 verschiedene SQL-Varianten braucht (mit und ohne s.*), wenn man das auch grundsätzlich mit s.* lösen kann.

Auch die Frage, warum an denn überhaupt eine Konstante braucht, wenn diese immer gesetzt wird und die SQL-Abfrage genauso gut vollständig im Code stehen könnte, statt über eine Konstante zu gehen. Ich habe zumindest keine Stelle gefunden, wo SPECIAL_CONDITIONS(_S) leer wäre oder auf Inhalt geprüft würde. Ist ja auch eine Konstante.

[noRiddle]

Das ist analog zu PRODUCTS_CONDITIONS/PRODUCTS_CONDITIONS_P gemacht worden und ich finde es sinnvoll. Bei allen Queries, auch zukünftigen in Erweiterungen, kann man somit einfach immer dieselben Conditions benutzen, die, da es um GROUP_CHECK geht (und bei den Specials darum ob Sonderangebot aktiv), auch immer benötigt werden.
Das *_S, bzw. *_P wird bei JOINs für die Aliasse benötigt und ist deshalb ebenfalls sinnvoll.

Warum man auch ohne JOINs Aliasse benutzen sollte erschließt sich mir nicht (weil du sagst "...wenn man das auch grundsätzlich mit s.* lösen kann").

Den Sinn deines letzten Satzes verstehe ich überhaupot nicht.

Wenn du in den Logs einen Fehler hattest, "dass s.status nicht Bestandteil der Spalten ist" wird das eine Erweiterung gewesen sein die einen Fehler in der betroffenen Query hatte.

Gruß,
noRiddle