Aktuell stand ich vor dem Problem ein größeres Datenvolumen in die SQL-Datenbank eines bestehendes Projekt zu integieren. Nach Wiederherstellung der Daten aus einem SQL-Hotbackup, bemerkte ich das die „neuen“ Datenbanken und Tabellen alle im Charset „latin1“ bzw. der Collation „latin1_german1_ci“ definiert waren, wo hingegen die bestehenden Datenbanken des Projekts alle im Charset „utf8“ definiert waren.
Das ist mehr als nur ein kosmetisches Problem, denn es bedeutet das sämtliche Felder die Zeichenketten enthalten eine andere binäre Kodierung bei Sonderzeichen wie Umlaute enthalten. MySQL als Datenbank-System ist zwar in sehr flexibler Weise darauf ausgelegt Daten aus unterschiedlichen Charset zu handhaben. Aber dazu müsste eine Applikation die auf die Datenbank zugreift bewusst das Charset anmelden in der sie die Daten dann erwartet. Dazu kann eine Applikation nach öffnen der Verbindung zu einem MySQL-Server folgende Variablen setzen:
Eine Sache scheinen die Entwickler bislang vergessen zu haben, welche besonders auffällt wenn man einen bestehenden Shop von einen anderen System zu Magento migrieren muss. Sobald eine Rechnung erstellt wird, wird von Magento automatisch eine fortlaufende Nummer erzeugt. Soweit werden schon mal die deutschen gesetzlichen Vorgaben an eine ordentliche Vergabe von Rechnungsnummern erfüllt. Allerdings hat ein Administrator leider keinerlei Möglichkeit die Rechnungsstartnummer nach Installation des Systems im Administrationmenu zu konfigurieren. Zudem sind die Rechnungsnummer immer automatisch 8-stellig und daher lautet die erste vergebene Nummer immer 10000001.
Feedback