WebsiteBaker Support (2.12.x) > Modules

Fehlermeldung in Bakery Shop Modul

<< < (3/3)

paulchen:
Du bist wirklich ein Fuchs, Uwe!
Mit deiner neuen save-orders.php gibt es keine Fehlermeldung mehr  :-D  (Y).

Jetzt würde mich aber schon interessieren, was der Grund für den Fehler war.


Nochmals ganz herzlichen Dank!

Paulchen

jacobi22:

--- Quote ---Jetzt würde mich aber schon interessieren, was der Grund für den Fehler war.
--- End quote ---

der "Fehler" ist die fehlende Maskierung der Werte  und ein scheinbar pingelicher Server. Das war auch das, was du zum Suchbegriff im Web gefunden hast.
Man darf nicht vergessen, das große Teile des Moduls aus 2011 stammen und so schauen die SQL-Befehle mittlerweile auch aus

jacobi22:

--- Quote ---würde mich aber schon interessieren, was der Grund für den Fehler war.
--- End quote ---

alte Schreibweise im Originalcode beim Upgrade des Stock (des vorhandenen Lagerbestandes) - save_orders.php


--- Code: ---$database->query("UPDATE ".TABLE_PREFIX."mod_bakery_items SET stock = stock + '$quantity' WHERE item_id = '$item_id'");
--- End code ---
das ergibt, ausgeschrieben, den Code  SET stock = stock +1, also stock = der Wert des Lagerbestandes plus den Wert der bestellten und nun stornierten Artikel (im Beispiel = 1)

die Schreibweise stock = stock + '$quantity' ist lt MySQL immer noch erlaubt, allerdings bestehen einige Server wohl auf eine Maskierung von $quantity.
Ich weiß, das bei dir der Strict-Mode von Mysql läuft und auch, das dieser so eingestellt ist, das ich ihn nicht 1:1 simulieren kann, von daher bin ich auch auf Nummer-Sicher gegangen und lese den Stock vorher separat aus, addiere das Storno dazu, so kann ich die Summe dann, wie gefordert, separat maskieren mit


--- Code: ---// Update item quantity;
                $sql = 'UPDATE `'.TABLE_PREFIX.'mod_bakery_items` SET '
                    .   '`stock` = \''.$iNewStockValue.'\' '
                    .   'WHERE `item_id`= \''.$item_id.'\' ';
--- End code ---

ausgeschrieben: SET stock = '11', statt der alten Form, die (summiert) so aussah  SET stock = 11

Im Anhang die Datei im ZIP-File (muß entpackt werden)

DarkViper:
Es ist das alte Problem mit dem Mischmasch der Datentypen bei Variablen und Datenfeldern.
Im strengen Strikt-Modus will die Datenbank für ein Tabellenfeld den Datentyp, für den es definiert ist.
Ein  Feld mit Typ INT will da eben einen Integer-wert, wohingegen ein Typ VARCHAR einen String verlangt. Die Zeiten von automatischen Datentypumwandlunge n werden, bzw. sind teilweise schon Vergangenheit.
So wie ich nach kurzem Überfliegen gesehen habe, enthält das Feld `stock` die Lagermenge des jeweiligen Artikels. Da ich nicht annehme, dass die Menge mit z.B. "3 Dutzend" oder "7 Klafter" angegeben wird, sollte da (nach meinem Verständnis) einfach eine Zahl zwischen 0 und n stehen. Was ich dabei nicht verstehe, ist der Umstand, dass das Feld als VARCHAR mit bis zu 20 Zeichen deklariert ist.  :|
Eine Änderung auf z.B. SMALLINT mit der (automatischen Länge 6) und einen Standardwert von 0 (Lager leer) würde ausreichen, Einen Lagerbestand (bzw. Fehlbestand) von -32768 bis +32767 darzustellen. Dann würden auch Rechenoperationen in SQL-Statements wieder funktionieren.
Das wäre dann kein Erste-Hilfe-Pflaster mehr, sondern eine dauerhafte und zukunftsfähige Lösung.

Das SQL müsste dann einfach von
$database->query("UPDATE ".TABLE_PREFIX."mod_bakery_items SET stock = stock + '$quantity' WHERE item_id = '$item_id'");

geändert werden auf:
$database->query('UPDATE `'.TABLE_PREFIX.'mod_bakery_items` SET `stock`=`stock`+'.(int) $quantity.' WHERE `item_id`='.$item_id);

oder etwas 'schöner'
$sSql = 'UPDATE `'.TABLE_PREFIX.'mod_bakery_items` '
          . 'SET `stock`=`stock`+'.(int) $quantity.' '  // das (int) castet $quantity und $item_id sicher nach Integer
          . 'WHERE `item_id`='.(int) $item_id;
$database->query($sSql);

Der Haken dabei: Wie immer, wenn an der Datenbank etwas geändert wird, müssen alle SQL-Statements, die auf die geänderte Tabelle (das Feld) zugreifen, entsprechend angepasst werden.

have a nice and sunny day...

jacobi22:

--- Quote from: DarkViper on June 02, 2019, 12:25:03 PM ---So wie ich nach kurzem Überfliegen gesehen habe, enthält das Feld `stock` die Lagermenge des jeweiligen Artikels. Da ich nicht annehme, dass die Menge mit z.B. "3 Dutzend" oder "7 Klafter" angegeben wird, sollte da (nach meinem Verständnis) einfach eine Zahl zwischen 0 und n stehen. Was ich dabei nicht verstehe, ist der Umstand, dass das Feld als VARCHAR mit bis zu 20 Zeichen deklariert ist.

--- End quote ---

Dank dir !
Die Updates des Stock finden noch an diversen weiteren Stellen statt, z.b. im Warenkorb beim herausnehmen und Einfügen von Artikeln, beim Kopieren von Items usw. Es ist also davon auszugehen, das da noch weitere Problemchen auftauchen.
An einigen Stellen wird der Stock-Wert mit is_numeric() geprüft, was zumindest klar stellen sollte, das hier mit Integer gearbeitet wird. Ich müßt jetzt in die Uralt-Versionen reinschauen, meine aber, das stock immer schon numerisch war und nicht etwa ein "none" für leer hatte
Eine Berechnung mittels Einheiten, wie es sie in anderen Shops als Zusatz-Addons gibt, ist hier nicht vorgesehen, theoretisch aber auch kein Problem.

Zusätzlich zum Stock-Wert gäbe es noch
- stock_mode (string / varchar) = i.d.r. "number oder image" - Ausgabe der Menge als Zahl oder Bild (grün 0 vorhanden, rot = wird knapp)
- stock_number (int) - Stückzahl, ab der Alarm für Knappheit gegeben wird
- out_of_stock_orders - (int - 0 oder 1) - Verkauf auch ohne Lagerbestand zulässig

Navigation

[0] Message Index

[*] Previous page