Fehlermeldung in Bakery Shop Modul

[paulchen]

Sorry, wenn ich hier falsch bin...

Folgende Fehlermeldung tritt reproduzierbar auf, wenn ich in der Auftragsverwaltung von Bakery einem Datensatz die Kategorie "stornieren" zuweise:

Code: [Select]

Truncated incorrect DOUBLE value: "
Der Befehl wird dennoch ausgeführt, der entsprechende Datenbankeintrag  "canceled" erzeugt, der Datensatz in der Benutzerverwaltung als "storniert" geführt. Im Datensatz sehe ich keine offensichtlichen Unrichtigkeiten ...

Dennoch wäre mir wohler, wenn es keine Fehlermeldung gäbe....
Kann mir jemand weiterhelfen?

mfg
Paulchen

[Gast]

hast du noch mehr Infos zum Fehler? Zeilennummer, Datei vielleicht?

[paulchen]

Nein, damit kann ich nicht dienen. Es wird lediglich im Forntend die unten stehende Fehlermeldung angezeigt.

[Gast]

die im Bild mitgeschickte Meldung stammt aber schon aus dem Backend 

bei welcher durchgeführten Aktion?

lesen will gelernt sein...  *grummel

steht ja oben im Eingangsthread - ich schau mal

[paulchen]

Klar - im BACKEND! 

Wenn ich in der Auftragsverwaltung bei einem Datensatz im Feld Status --> stornieren auswähle und per Klick auf Speichern bestätige...

[paulchen]

Tante Goo bringt eine Menge Anzeigen, wenn man die Fehlermeldung als Suchtext eingibt.
Demnach ist es eine Fehlermeldung von MYSQL.

[Gast]

kommt aus save_orders.php, Zeile 42 und kann m.E. nur auftreten, wenn die Quantity oder die Item-ID == 0 ist
dieses Update soll dem Lagerbestand die zuvor in der Bestellung "weggenommenen" Artikel wieder hinzufügen

Nun wirst du nicht am laufendem Band Bestellungen stornieren, aber vielleicht kannst du beim nächstem Mal  in der Tabelle mod_bakery_items vorher kontrollieren, was bei "stock" drin steht
dann in der mod_bakery_orders, was als "quantity" drin steht und dann beides vergleichen nach dem Canceln.
Man müßte sich wohl den gesamten Vorgang anschauen, was da schon bis dahin passiert, wenn z.b. bestellt, aber nicht bezahlt wurde, z.b. Paypal

Das einzige, was passieren kann, ist ein falscher Lagerbestand, sofern dieser überhaupt exakt geführt wird.

[paulchen]

Ich habe einen Dummy eingegeben und damit kontrolliert.
Der Lagerbestand wird bei mir nicht geführt.
"stock" in mod_bakery_items ist sowohl vor als auch nach der Stronierung leer.
"quantity" steht vorher und nachher auf 1.

Lassen wir es dabei: Ich habe im Jahr knapp eine Handvoll Stornierungen und außer der Anzeige der Fehlermeldung sehe ich keine Auswirkungen auf den Datenbestand.
Damit kann ich leben...

Ich danke dir ganz herzlich für deine Bemühungen.

mfg
Paulchen

[Gast]

Lassen wir es dabei: Ich habe im Jahr knapp eine Handvoll Stornierungen und außer der Anzeige der Fehlermeldung sehe ich keine Auswirkungen auf den Datenbestand.
Damit kann ich leben...

ich nicht   

heißt das, du hast diese Anzeige bei jeder von dir durch geführten Stornierung und kannst sie somit immer wieder reproduzieren?

Wenn JA, ich vermute etwas und lass dir mal per Mail eine geänderte save-orders.php zukommen

[Gast]

Mail ist raus an die gmx.Adresse-das Zip entpacken und die alte save_orders.php überschreiben

Lt meinen Rückmeldungen ist das Problem wohl schon länger so, mindestens seit Beginn des Jahres

[paulchen]

Du bist wirklich ein Fuchs, Uwe!
Mit deiner neuen save-orders.php gibt es keine Fehlermeldung mehr    .

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


Nochmals ganz herzlichen Dank!

Paulchen

[Gast]

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

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

[Gast]

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

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

Code: [Select]

$database->query("UPDATE ".TABLE_PREFIX."mod_bakery_items SET stock = stock + '$quantity' WHERE item_id = '$item_id'");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: [Select]

// Update item quantity;
                $sql = 'UPDATE `'.TABLE_PREFIX.'mod_bakery_items` SET '
                    .   '`stock` = \''.$iNewStockValue.'\' '
                    .   'WHERE `item_id`= \''.$item_id.'\' ';
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...

[Gast]

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.

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