Moin, wir hatten mit einem Subshop Probleme, und haben diesen neu angelegt. ID 6. Wenn ich nun die Einträge in der s_core_translations umschreibe auf die ID 6 bekomme ich diesen Fehler: update s_core_translations set objectlanguage=6 where objectlanguage=‚en‘ Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '2147483647' for key 'PRIMARY'' in /var/www/web508/html/solarripp/store/engine/Enlight/Vendor/Zend/library/Zend/Db/Adapter/Pdo/Abstract.php:263 Stack trace: #0 /var/www/web508/html/solarripp/store/engine/Enlight/Vendor/Zend/library/Zend/Db/Adapter/Pdo/Abstract.php(263): PDO-\>exec('??????REPLACE I...') #1 /var/www/web508/html/solarripp/store/engine/Enlight/Enlight/Components/Adodb.php(83): Zend\_Db\_Adapter\_Pdo\_Abstract-\>exec('??????REPLACE I...') #2 /var/www/web508/html/solarripp/store/engine/core/class/inherit/myArticles.php(105): Enlight\_Components\_Adodb-\>Execute('??????REPLACE I...') #3 /var/www/web508/html/solarripp/store/engine/core/class/sRewriteTable.php(66): myArticles-\>sCreateTranslationTable() #4 /var/www/web508/html/solarripp/store/engine/Shopware/Plugins/Default/Frontend/RouterRewrite/Bootstrap.php(148): sRewriteTable-\>sCreateRewriteTable('2012-03-01 08:4...') #5 /var/www/web508/html in /var/www/web508/html/solarripp/store/engine/Enlight/Vendor/Zend/library/Zend/Db/Adapter/Pdo/Abstract.php on line 280 Aber ich kann keinen doppelten Primärschlüssel finden. Wo liegt der Hund begraben? Danke
Habe eben in dem betroffenen Shop noch mal die Dateien überprüft. Es gibt keine Anpassungen, alle Dateien sind original 3.5.6. Es geht nun nur darum, wie ich die übersetzungen der Artikel, Varianten etc. von dem alten Subshop (EN) auf den neuen Shubshop (6) bekomme. Mein logisches Vorhaben ist ja dies: update s_core_translations set objectlanguage=6 where objectlanguage=‘en’ Aber dann erscheint die gepostete Fehlermeldung. Shopware:shopware:, habt ihr einen Tipp?
Hi, mein heißer Tipp ist, dass der Auto-Inkrement Wert der Tabelle s_articles_translations sein Limit von 32 Bit erreicht hat. Das eigentlich Problem dabei besteht aber darin, dass in der Klasse sArticles um Zeile 2150 (sCreateTranslationTable) rum ein REPLACE INTO auf diese Tabelle verwendet wird. An sich ist das nicht weiter schlimm, allerdings wird der Primärschlüssel dabei neu erzeugt (REPLACE löscht den alten Datensatz und fügt einen neuen hinzu, was wiederum das Autoinkrement aktiviert). Es würde hier Sinn machen den ohnehin als unique gekennzeichneten Schlüssel aus articleId und languageId als Primärschlüssel zu verwenden, aber manchmal sind die Wege des Herrn halt unergründlich… Ich würde dir vorschlagen einmal das Feld Id auf unsigned zu setzen und dann zu schauen, ob es wirklich daran liegt (vorher ein Backup machen). Dann gibt es mehrere Varianten, wie man das lösen könnte. Nichtsdestotrotz wäre hier ein vernünftiges Datenbankdesign seitens Shopware wünschenswert.
Danke für den heißen Tipp 
War ein Volltreffer. Nach entfernen des auto_imcrement funktioniert es. Ich hab es zwar noch nicht ganz verstanden, aber ergal. Mag wohl am Freitag Abend liegen. Ich schulde dir ein Bier 
Evtl. am Community Day, wer weiß… Schönes Wochenende
könnte das zukünftige Probleme geben, wenn ich dies nun so lasse?
Das kann ich dir nicht sagen. Meine Empfehlung war ja nicht das autoincrement zu deaktivieren, sondern den Datentyp auf unsigned zu ändern, das verdoppelt die Anzahl der verfügbaren Ids. Alternativ kannst Du den Datentyp auf Bigint ändern, falls verfügbar, das schafft dir mehr Luft nach oben. Langfristig kann eine echte Lösung nur durch Shopware herbeigeführt werden, da sie in den Core aufgenommen werden muss. PS: Ich trinke kein Bier, aber 'ne Milch vielleicht
Hallo zusammen bzw. Moin Ottscho, ich denke nicht, dass hier generell was an der Datenbank geändert werden sollte. Ausschlaggebend ist hier irgendein anderes Problem. Unter normalen Umständen kann man solchen hohen IDs gar nicht erreichen. Da sind also alte Daten vorhanden, ggf. von tausenden Importen etc. oder alten Tests. Im Normalfall kann man das gar nicht hinbekommen / erreichen! Autoincrement sollte man auf jeden Fall niemals entfernen! Das hat ja Auswirkungen auf den gesamten Shop u. U. Besser wäre die ID von INT auf BIGINT zu ändern. Generell sollte aber geprüft werden, wie der Shop arbeitet,da solche Werte im normalen Leben so nicht einfach auftreten können. So viele Einträge können da normal definitiv nicht vorliegen, sondern die ID, vermute ich, startet dort einfach viel zu noch.
Moin, Ich bin mir auch nicht sicher, ob es wirklich damit zu tun hat. Die Tabelle hat 50361 Datensätze. Die kleinste ID ist 36 und die Grösste 52143. Ich habe ja nun das Attribut unsign bei dem Feld ID hinzugefügt und Auto_imcrement entfernt. Ich muss mal zum Test einen neuen Artikel mit Übersetzung anlegen. Mal schauen was passiert. Aber jetzt erst mal Frühstücken. Meld mich später… @ovi Ich weiß nicht ob es auf dem Community Das Milch gibt. Evtl. ne Cola Light
Das Autoinkrement würde ich ebenfalls drin lassen, wie gesagt… ich weiß nicht, wie/wo es ggf. Verwendung findet. Und ich bleibe dennoch dabei, dass es irrsinnig ist bei einer Verknüpfungstabelle einen künstlichen Primärschlüssel einzufügen, wenn es doch den perfekten(!) natürlichen Kandidaten gibt, der ja ohnehin über den Unique Index forciert wird… Ich kann keine Aussage darüber treffen, wie häufig die sCreateTranslationTable Methode aufgerufen wird, vielleicht jedes Mal, wenn der Cache gelöscht wird, oder wenn irgendetwas an Subshops geändert wird, oder Montags 2 mal, Dienstags dafür 5, ich habe keine Ahnung! Aber gerade bei Verwendung von REPLACE INTO wird jedesmal das autoinkrement hochgezählt, da wäre die Verwendung von INSERT … ON DUPLICATE KEY UPDATE… sinnvoller. Das spielt für mich aber auch eigentlich eher eine untergeordnete Rolle. Fakt ist, dass solche Probleme durch eine durchdachtere Datenbankstruktur vermeidbar sind.