Moin,
bei der Version 2.05 gab es ja einen Gubfix.
"Bugfix: Bei großen Bestellungen konnte es bei bestimmten Datenbankkonfigurationen zu einem Fehler kommen. Gefixt."
Wie hat sich der Fehler den bemerkbar gemacht?
Gruß
Thorsten
Version 2.05 Bugfix Änderung
-
pichel
- Administrator
- Beiträge: 1494
- Registriert: So 13. Sep 2015, 19:48
- Wohnort: Hamburg
- Kontaktdaten:
Re: Version 2.05 Bugfix Änderung
Hallo,
der von der TSE zu signierende text, der eben abhängig von der Bestellung ist, wird in der Tabelle operations in einer Spalte signtxt gesichert. Diese war bis 2.0.4 vom Typ VARCHAR, und je nach Konfiguration der Datenbank gab es einen Fehler, wenn der zu signierende Text eben länger als die festgelegte maximallänge war.
Gruß,
Stefan
der von der TSE zu signierende text, der eben abhängig von der Bestellung ist, wird in der Tabelle operations in einer Spalte signtxt gesichert. Diese war bis 2.0.4 vom Typ VARCHAR, und je nach Konfiguration der Datenbank gab es einen Fehler, wenn der zu signierende Text eben länger als die festgelegte maximallänge war.
Gruß,
Stefan
Stefan Pichel
Entwickler der Kassensoftware OrderSprinter (http://www.ordersprinter.de)
Entwickler der Kassensoftware OrderSprinter (http://www.ordersprinter.de)
Re: Version 2.05 Bugfix Änderung
Hallo zusammen,
ich weiß, das ist ein ziemlich alter Forenbeitrag, aber mein Bugreport scheint genau hier zu passen.
Vor etwa sechs Jahren wurde in operations.php offenbar folgender Code eingefügt:
Dadurch wird der String auf 120 Zeichen gekürzt. Das Problem ist allerdings, dass strlen() und substr() auf Bytes arbeiten.
Enthält ein Artikelname Sonderzeichen (bei uns war es z. B. „Radler-Süß“), kann es (scheinbar völlig zufällig und sehr sporadisch) passieren, dass substr() genau mitten in einem UTF-8-Multibyte-Zeichen abschneidet. Beim Speichern des ungültigen UTF-8-String in der Datenbank führte das anschließend zu folgendem PHP-Fehler:
Erst wenn die komplette Bestellung verworfen und anschließend neu erfasst wurde, funktionierte alles wieder. Dabei wurde die Reihenfolge der Bestellung (zufällig) geändert, sodass der Schnittpunkt nicht mehr mitten in einem Multibyte-Zeichen lag.
Die Lösung besteht darin, UTF-8-fähige Funktionen zu verwenden, z. B. mb_strlen() und mb_substr(), damit immer an einer gültigen Zeichenposition abgeschnitten wird (wobei mit diesen Funktionen längere Strings als 120 Byte entstehen können).
Ich habe es jetzt so gelöst:
Folgende Zeile ist ebenso anfällig für Multi-Byte-Zeichen, hat aber wohl keine Funktion mehr
Gruß Frank
ich weiß, das ist ein ziemlich alter Forenbeitrag, aber mein Bugreport scheint genau hier zu passen.
Vor etwa sechs Jahren wurde in operations.php offenbar folgender Code eingefügt:
Code: Alles auswählen
if (strlen($signtxt) > 120) {
$signtxt = substr($signtxt, 0, 117) . "...";
}Enthält ein Artikelname Sonderzeichen (bei uns war es z. B. „Radler-Süß“), kann es (scheinbar völlig zufällig und sehr sporadisch) passieren, dass substr() genau mitten in einem UTF-8-Multibyte-Zeichen abschneidet. Beim Speichern des ungültigen UTF-8-String in der Datenbank führte das anschließend zu folgendem PHP-Fehler:
Code: Alles auswählen
[Sun Jun 28 17:41:02.349905 2026] [php:error] [pid 23899] [client 192.168.0.208:50322] PHP Fatal error: Uncaught PDOException: SQLSTATE[22007]: Invalid datetime format: 1366 Incorrect string value: '\\xC3...' for column `ordersprinter`.`os_operations`.`signtxt` at row 1 in /var/www/html/php/commonutils.php:510\nStack trace:\n#0 /var/www/html/php/commonutils.php(510): PDOStatement->execute()\n#1 /var/www/html/php/utilities/operations.php(51): CommonUtils::execSql()\n#2 /var/www/html/php/queuecontent.php(1977): Operations::createOperation()\n#3 /var/www/html/php/queuecontent.php(1908): QueueContent::signAtTSE()\n#4 /var/www/html/php/queuecontent.php(1533): QueueContent->addProductListToQueueCore()\n#5 /var/www/html/php/queuecontent.php(125): QueueContent->addProductListToQueue()\n#6 /var/www/html/php/contenthandler.php(75): QueueContent->handleCommand()\n#7 {main}\n thrown in /var/www/html/php/commonutils.php on line 510, referer: http://192.168.0.100/waiter.htmlDie Lösung besteht darin, UTF-8-fähige Funktionen zu verwenden, z. B. mb_strlen() und mb_substr(), damit immer an einer gültigen Zeichenposition abgeschnitten wird (wobei mit diesen Funktionen längere Strings als 120 Byte entstehen können).
Ich habe es jetzt so gelöst:
Code: Alles auswählen
if (strlen($signtxt) > 120) {
$signtxt = mb_strcut($signtxt, 0, 117, 'UTF-8') . "...";
}Code: Alles auswählen
$signtxt_ascii = preg_replace('/[[:^print:]]/', '', $signtxt);