Keine Versandarten gefunden

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.

Ich habe es eben mal kurz auf dem Stage-Server getestet, unser Teststatement hat zumindest danach tatsächlich funktioniert …. also rein auf SQL Basis.
Die Gegenprobe war auch erfolgreich, nur mit den anderen Settings, die wir bisher gesetzt hatten liefert das Teststatement wieder falsche Ergebnisse (zu viele in diesem Fall).

[B]Sprich - das Flag scheint auf den ersten Blick tatsächlich zu helfen[/B] :slight_smile:
Allerdings - ein [B]Problem[/B] hatte ich dabei: wenn ich die Einstellung wie unten beschrieben bei jedem Aufruf der index.php gesetzt habe gab es im Frontend öfters Timeouts … was sehr seltsam ist und was ich mir gerade nicht erklären kann, zumal auf dem Stage auch kein Traffic ist :frowning:

@oxid-flo: das Problem mit fehlenden Artikeln im Admin kann ich damit nicht nachvollziehen … aber ob es evtl. andere Nebenwirkungen hat müsste man noch ausführlich testen, s.o.

Vielen Dank, “Stefam”, für die Rückmeldung.

Aktuell habe ich die Lösung, dass ich die index.php immer wieder abändere bzw. eine “alte” Version habe und die “Neue”.

Wenn ich Artikel hinzufügen will im Admin, dann lege ich die alte index.php im Server ab.
Dann funktioniert es wenigstens, dass ich die Artikel suchen kann und im Admin die Bestellung abändern kann.

Dann kann aber allerdings in dieser Zeit kein Kunde im eShop bestellen (oder halt mit viel Glück).

Sobald ich im Admin keine Artikel mehr zur Bestellung hinzufügen muss, lege ich wieder die neue index.php im Server ab.

Ich mache dies halt nun so lange, bis ich eine neue Lösung im Forum gefunden habe…hilft ja nichts…leider…

Mich wundert es nur, dass nicht mehr Oxid-User dieses Problem haben…

Hallo,

hatte bereits einen anderen Thread zu dem Thema eröffnet, einer meiner Kunden hat noch einen älteres Shopsystem und will dieses aus div. Gründen auch noch bis mind. Ende des Jahres so beibehalten, dass Problem bei seiner Version (CE 4.5.11) ist, dass die index.php etwas anders aufgebaut ist, ergo wo genau muss der angegebene Code platziert werden?

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

Grüße aus Berlin

Ich würde es mal vor “//Starting the shop” einfügen.

Hallo Leo,

funktioniert leider nicht, egal wo ich es einfüge, ich bekomme immer einen “internal server error” bzw. “wegen Wartungsarbeiten derzeit offline”.

Weitere Vorschläge?

Grüße aus Berlin

Hallo itnic, so geht es nicht?

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

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

Ich habe mich entschieden, derived_merge=off’ wieder wegzunehmen, weil der shop sehr langsam wird.
Ich habe jetzt wieder das Problem, daß keine Versandart angeboten wird. Folgendes hat dann geholfen: Alle Länder aus Zugeordnete Länder löschen, Views updaten, wieder alles Länder zu Zugeordnete Länder hinzufügen, dann geht es wieder für eine Weile, bis man zu viel navigiert oder sich mit anderem Konto anmeldet. (Alle Länder zuordnen und keine Land zuordnen ist äquivalent, normaleweise ordnet man gar kein Land zu. So steht es in der Bedienungsanleitung: “Benutzer und Benutzergruppen können, müssen aber nicht zugeordnet sein. Fehlt letztere Zuordnung, gilt die Versandart für alle Benutzer.”)

Das ist natürlich noch keine Lösung, weil es nur für kurz hilft. Aber es zeigt, daß man nicht etwas bei den Regeln falsch eingestellt haben muß, und daß es wohl mit mysql 5.7 zu tun hat.

Mich würde interessieren, was für OXID-Shop-Versionen Ihr besitzt. Ich habe 4.9.7. CE. Das Problem scheinen ja nur wenige zu haben. Weiß jemand, ob ein Update hilft? Und wer weiß, wie es mit mysql 5.8 sein wird?

Und sind nur shops bei Alfahosting betroffen?

Anhang:

Leider funktioniert jetzt das backend nicht mehr. Erst ging es noch eine Weile. Die Drop-Down-Boxen sprechen nicht mehr an. Hier ist der Errorlog:

oxSystemComponentException-oxException (time: 2016-11-18 11:08:34): [0]: ERROR_MESSAGE_SYSTEMCOMPONENT_FUNCTIONNOTFOUND
Stack Trace: #0 /var/www/x/html/core/oxutilsobject.php(188): oxUtilsObject->_getObject(‘oxsystemcompone…’, 0, Array)
#1 [internal function]: oxUtilsObject->oxNew(‘oxSystemCompone…’)
#2 /var/www/x/html/core/oxfunctions.php(371): call_user_func_array(Array, Array)
#3 /var/www/x/html/core/oxview.php(532): oxNew(‘oxSystemCompone…’)
#4 /var/www/x/html/core/oxshopcontrol.php(347): oxView->executeFunction(‘recommlists’)
#5 /var/www/x/html/core/oxshopcontrol.php(126): oxShopControl->_process(‘oxwcookienote’, ‘recommlists’, Array, Array)
#6 /var/www/x/html/core/oxwidgetcontrol.php(73): oxShopControl->start(‘oxwcookienote’, NULL, Array, Array)
#7 /var/www/x/html/core/smarty/plugins/function.oxid_include_widget.php(56): oxWidgetControl->start(‘oxwcookienote’, NULL, Array, Array)
#8 /var/www/x/html/tmp/smarty/08cd8ec20b6974b71f3e344beaab3f34^%%93^93D^93D6031B%%header.tpl.php(10): smarty_function_oxid_include_widget(Array, Object(Smarty))
#9 /var/www/x/html/core/smarty/Smarty.class.php(1870): include(‘/var/www/x…’)
#10 /var/www/x/html/tmp/smarty/08cd8ec20b6974b71f3e344beaab3f34^%%36^366^366ECF91%%page.tpl.php(23): Smarty->_smarty_include(Array)
#11 /var/www/x/html/core/smarty/Smarty.class.php(1870): include(‘/var/www/x…’)
#12 /var/www/x/html/tmp/smarty/08cd8ec20b6974b71f3e344beaab3f34^%%DA^DA0^DA07DFA9%%err_404.tpl.php(21): Smarty->_smarty_include(Array)
#13 /var/www/x/html/core/smarty/Smarty.class.php(1264): include(‘/var/www/x…’)
#14 /var/www/x/html/core/oxutilsview.php(104): Smarty->fetch(‘message/err_404…’)
#15 /var/www/x/html/core/oxutils.php(1489): oxUtilsView->getTemplateOutput(‘message/err_404…’, Object(oxUBase))
#16 /var/www/x/html/core/oxfunctions.php(236): oxUtils->handlePageNotFoundError(‘’)
#17 /var/www/x/html/application/controllers/rss.php(196): error_404_handler()
#18 /var/www/x/html/core/oxview.php(522): Rss->recommlists()
#19 /var/www/x/html/core/oxshopcontrol.php(347): oxView->executeFunction(‘recommlists’)
#20 /var/www/x/html/core/oxshopcontrol.php(126): oxShopControl->_process(‘rss’, ‘recommlists’, NULL, NULL)
#21 /var/www/x/html/core/oxid.php(40): oxShopControl->start()
#22 /var/www/x/html/index.php(26): OXID::run()
#23 /var/www/x/html/oxseo.php(44): require(‘/var/www/x…’)
#24 {main}

Faulty component –> recommlists

Im Moment ist es eher ein Rumbasteln als Mauern. Mit derived merge off meckert Alfahosting, daß die Last zu groß sei. Ohne derived merge off, wie beschrieben! Ich werde vielleicht mal fragen, ob ich auf mysql 5.6 downgraden kann.

Entschuldigung! Es muß ein Java-Problem mit dem Browser sein. Ich melde mich nochmal, welches Problem eigentlich durch das fehlende derived merge off gemacht wird

Hallo,

in unserem Shop (Version 4.9.4) mit mySQL 5.7 tritt dieses Problem ebenfalls auf. Auch die Tatsache, dass derived_merge=off eine sehr hohe Prozessorlast durch den mySQL-Server hevorruft kann ich bestätigen.

So wie ich das sehe, handelt es sich hier um einen Bug in OXID (bitte korrigieren Sie mich, falls ich falsch liege).

Hat bereits Jemand Fortschritte in Richtung einer Lösung des Problems erzielt?

[QUOTE=MichaelH;184160]Hallo itnic, so geht es nicht?

Ich habe mich entschieden, derived_merge=off’ wieder wegzunehmen, weil der shop sehr langsam wird.
Ich habe jetzt wieder das Problem, daß keine Versandart angeboten wird. Folgendes hat dann geholfen: Alle Länder aus Zugeordnete Länder löschen, Views updaten, wieder alles Länder zu Zugeordnete Länder hinzufügen, dann geht es wieder für eine Weile, bis man zu viel navigiert oder sich mit anderem Konto anmeldet. (Alle Länder zuordnen und keine Land zuordnen ist äquivalent, normaleweise ordnet man gar kein Land zu. So steht es in der Bedienungsanleitung: “Benutzer und Benutzergruppen können, müssen aber nicht zugeordnet sein. Fehlt letztere Zuordnung, gilt die Versandart für alle Benutzer.”)

Das ist natürlich noch keine Lösung, weil es nur für kurz hilft. Aber es zeigt, daß man nicht etwas bei den Regeln falsch eingestellt haben muß, und daß es wohl mit mysql 5.7 zu tun hat.

Mich würde interessieren, was für OXID-Shop-Versionen Ihr besitzt. Ich habe 4.9.7. CE. Das Problem scheinen ja nur wenige zu haben. Weiß jemand, ob ein Update hilft? Und wer weiß, wie es mit mysql 5.8 sein wird?

Und sind nur shops bei Alfahosting betroffen?

Anhang:

Leider funktioniert jetzt das backend nicht mehr. Erst ging es noch eine Weile. Die Drop-Down-Boxen sprechen nicht mehr an. Hier ist der Errorlog:

Im Moment ist es eher ein Rumbasteln als Mauern. Mit derived merge off meckert Alfahosting, daß die Last zu groß sei. Ohne derived merge off, wie beschrieben! Ich werde vielleicht mal fragen, ob ich auf mysql 5.6 downgraden kann.

Entschuldigung! Es muß ein Java-Problem mit dem Browser sein. Ich melde mich nochmal, welches Problem eigentlich durch das fehlende derived merge off gemacht wird[/QUOTE]

Moin zusammen,

gibt es irgendwelche Neuigkeiten bzgl. dieses nervigen Themas? Ich habe leider das gleiche Problem und bin absolut ratlos.
Bin auch bei Alfahosting mit der Version CE 4.7.8

For the record: ab Version 4.10.2 ist Oxid kompatibel mit Mysql 5.7. Hier https://bugs.oxid-esales.com/view.php?id=6497 sind die Änderungen verlinkt. Mit diesen Änderungen gibt es im Gegensatz zu derived_merge=off keine Performance-Einbußen.