Keine Versandarten gefunden

Wir haben genau das gleiche Problem - seit ca. 2-3 Tagen.

Bei uns kam erst der Fehler, dass Bestellungen keine Versandart mehr angezeigt haben und nachdem man diese als “versendet” markiert hat, wandelte sich die Zahlungsart in “Empty” um. Nun geht aber fast gar nichts mehr.

Sind gerade auch dabei zu erfragen ob es ein MySQL-Update gab - bin gespannt. :slight_smile:

Für alle mit dem selben Problem, haben es gerade mit Julischka gelöst:
Die index.php des Shops um folgendes erweitern:

$oDb = oxDb::getDb();
$sQ = “SET SESSION optimizer_switch = ‘derived_merge=off’”;
$oDb->execute($sQ, array());

Danach sollten die Fehler weg sein.

Leider hilft das nicht immer. Wir hatten auch so einen Fall nach Update auf MySQL 5.7 und wir hatten serverseitig alles so eingestellt, wie es hier (in den Kommentaren) angegeben wurde: https://bugs.oxid-esales.com/view.php?id=6247 . Sah auch zunächst so aus, als würde das helfen, aber nach ein paar Tagen tauchte das Problem wieder auf.

Siehe auch hier: http://forum.oxid-esales.com/showthread.php?p=182365#post182365.

[KORREKTUR]
Ich sehe gerade, dass ‘derived_merge’ gar nicht enthalten ist in den Settings, die im Bugtracker angegeben wurden. Vielleicht ist das dann doch der entscheidende Hinweis! Ich werde mal testen.

Ich habe gerade eine Bestellung aus dem Ausland hereinbekommen,es ist also nur sporadisch.
“Derived merge off” hilft leider nichts.

Auch Browser- cookies löschen, hilft nichts.

Liegt es vielleicht an einem Modul? Benutzt Ihr auch alle amazon-payment von JAG?

@patchwork.de:Englische Fehlermeldung kam bei skipped View, weil ich englisch als Hauptsprache habe.

Ich habe im falschen thread gepostet. Es wollte eigentlich dieser http://forum.oxid-esales.com/showthread.php?t=40141 sein.


Oxid 4.9.7
Server:
Perl-Version: 5.20
MySQL-Version: 5.7
.htaccess:
AddHandler x-httpd-php54 .php

Hallo - nach der Umstellung auf MySQL 5.7 laufen die Versandkostenberechnungen nicht mehr wie gewohnt. Es kommt bei bislang funktionalen Versandregeln zu sporadischem Fehlverhalten der Berechnung der Versandkosten im Shop. Auch ein Update auf die 4.10.1 bringt keine Änderung.

@Marco äußerte einen Verdacht. Welcher wäre das?

Vielleicht hat es etwas damit zu tun, daß manchmal keine Versandkosten für das Land gefunden werden.

Ein Workaround ist, die index.php so zu ändern:

require_once dirname(FILE) . “/bootstrap.php”;
//wegen Problem mit mySql 5.7
$oDb = oxDb::getDb();
$sQ = “SET SESSION optimizer_switch = ‘derived_merge=off’”;
$oDb->execute($sQ, array());

[QUOTE=Marco Steinhaeuser;182355]Hallo @ab2211,

kannst Du mal herausbekommen, welche MySQL-Version bei Dir im Einsatz ist? Wir haben hier so einen Verdacht…

Gruß[/QUOTE]

Ich habe in meiner Not auch bei Alfahosting nachgefragt, ob sich etwas geändert hat. Angeblich haben sich PHP und MySql Versionen in dem Zweitraum geändert.

Administration: Confixx 3.3.1
PHP-Version(en): 4.4, 5.2 bis 5.6, 7.0
Perl-Version: 5.20
MySQL-Version: 5.7

PHP ist aktuell auf 5.3.

“die einzigen Änderungen in letzter Zeit fanden, wie angekündigt, am 19.08.2016 statt. Hier wurden die PHP-Versionen sowie die MySQL-Version aktualisiert.”

Man mag es kaum glauben, aber nach Ewigkeiten, geht es nun wieder! Anfangs dachte ich, einmal kurz drüberschauen würde reichen…

Für mich war dann, nebst der Provider-Anfrage, wirklich nur noch ein “Reset” hilfreich.
Doch, das schlimme ist: Wo der Fehler lag weiss ich nicht!

Ok - vielen Dank für die guten Beiträge hier im Forum. Zumindest können die Kunden wieder bestellen. Komischerweise habe ich nun aber noch folgenden Fehler entdeckt. Dieser tritt defintiv nur auf wenn man die index.php abändert mit dem oben genannten Code.

Fehler im Admin:
Unter “Bestellungen verwalten” > “Bestellungen” > “Artikel” kann man nun keinen Artikel mehr hinzufügen. Unter Eingabe der Artikelnummer wird kein Artikel mehr gefunden. Es erfolgt der Hinweis “Leider keine Artikel gefunden.”

Sobald ich die index.php wieder zurück ändere und tmp leere etc. werden die Artikel wieder gefunden. Allerdings können dann auch keine Kunden bestellen…

Ist dies bei euch auch so? Wer kann sich dem Code nochmals annehmen?

Vielen Dank!

Die Datenbank-Views hattest Du wohl nach der Änderung bereits neu generiert, oder?

Gruß

Ja, Views wurden aktualisiert. Cache geleert…
Fehler tritt trotzdem auf…ich werden wie oben beschrieben keine Artikel mehr gefunden…

Habt ihr noch das gleiche Problem?

Im Admin unter Eingabe der Artikelnummer wird kein Artikel mehr gefunden…

Ich würde mich über Rückmeldung sehr freuen!

Bei mir werden neue Bilder nicht mehr in die “generated” Ordner kopiert.

Verstehe ich es richtig, dass es bei Dir jetzt auch ohne die vom MichaelH vorgeschlagene Änderung (siehe unten) in index.php geklappt hat?

require_once dirname(__FILE__) . "/bootstrap.php";

//wegen Problem mit mySql 5.7
$oDb = oxDb::getDb();
$sQ = "SET SESSION optimizer_switch = 'derived_merge=off'";
$oDb->execute($sQ, array());

Ja, es ging so.

Komisch, dass keiner die selben Probleme hat.
Die Kunden können zwar wieder bestellen, aber dafür werden im Admin auch keine Artikel mehr gefunden.

Siehe Beitrag 09-04-2016, 03:56 PM

Könnt ihr bitte mal bei euch testen?

[QUOTE=MichaelH;182376]Vielleicht hat es etwas damit zu tun, daß manchmal keine Versandkosten für das Land gefunden werden.

Ein Workaround ist, die index.php so zu ändern:

require_once dirname(FILE) . “/bootstrap.php”;

//wegen Problem mit mySql 5.7
$oDb = oxDb::getDb();
$sQ = “SET SESSION optimizer_switch = ‘derived_merge=off’”;
$oDb->execute($sQ, array());

[/QUOTE]

Was sollte da eigentlich geändert werden? In meiner index.php sind diese Angaben bereits vorhanden. So sieht es aus:

<?php
/**

  • This file is part of OXID eShop Community Edition.
  • @version SVN: $Id: index.php 46036 2012-06-08 13:59:30Z tomas $
    */

require_once dirname(FILE) . “/bootstrap.php”;

$oDb = oxDb::getDb();
$sQ = “SET SESSION optimizer_switch = ‘derived_merge=off’”;
$oDb->execute($sQ, array());

//Starts the shop
Oxid::run();

Danke!

Interessant. In der aktuellen Entwicklung sieht diese Datei so aus:

Evntl. hat ein Script des Hostingproviders für diese Einträge gesorgt?

Gruß

Wie Andreas Ziethen hier schon schrieb hatten wir extreme Probleme mit einer EE ab einer gewissen Serverlast und zwar sowohl mit MySQL 5.6 als auch mit bisher allen 5.7 Versionen. Es gab dann entweder gar keine Versandarten mehr in allen Subshops oder es wurden mal welche angezeigt, mal nicht… manchmal wurden auch mehr Versandarten angezeigt als eigentlich für die aktiven Kundengruppen zugeordnet o.ä.

Wir haben im Zusammenspiel mit ScaleCommerce alle Optimizer Flags ausprobiert, die im Bugtracker empfohlenwurden, jedoch ohne merklichen Erfolg.
Allerdings wurde das jetzt aufgetauchte und hier empfohlene Flag “[B]derived_merge=off[/B]” dort nicht erwähnt, evtl. hilft das ja nun tatsächlich, das konnte ich bisher noch nicht verifizieren.

Uns hat am Ende dann nur geholfen, für die Klassen “[B]oxdeliverylist, oxdeliverysetlist und oxdiscountlist[/B]” Module zu schreiben, die jeweils die Funktion “[B]_getFilterSelect()[/B]” überschreiben und alle Vorkommen von “IF(EXISTS…” eliminieren. Das macht das SQL zwar etwas umfangreicher, aber damit hatten wir dann keine Probleme mehr mit Versandarten, Zahlungsarten oder Discounts, auch nicht unter Hochlast.