XML aus MySQL auslesen

[atomicbunny]

Jau!!! Danke! Sagst Du mir auch kurz was es mit dem increment auf sich hat? Damit ich es auch verstehe.

Und kann ich so etwas „Verdünnung P, 1 l“ beim Import auch korrigieren? Shop DB ist utf-8, und die XML Dateien sollen es angeblich auch sein. Wohl aber irgendwie doch nicht.



Viele Grüße

Mario

[urvater]

Zitat von atomicbunny

Jau!!! Danke! Sagst Du mir auch kurz was es mit dem increment auf sich hat? Damit ich es auch verstehe.

Meinst du die Möglichkeit in MySQL eine Spalte auf atuo_increment zu setzen?
Dann wäre es eine automatisierte Nummerierung der Spalten durch MySQL.

Zitat von atomicbunny

Und kann ich so etwas „Verdünnung P, 1 l“ beim Import auch korrigieren? Shop DB ist utf-8, und die XML Dateien sollen es angeblich auch sein. Wohl aber irgendwie doch nicht.

Deine Spalten in der neuen DB stehen auf COLLATE latin1_general_ci. Also nicht utf-8.
Bin mir nicht sicher aber mit mysql-set-charset solltest du den verwendeten Zeichensatz der Tabelle mitteilen können.

Alternative: Die XML Datei mit dem Editor öffnen -> Speichern unter ->ANSI wählen.
In der XML UTF-8 auf iso-8859-1 abändern.
Funktioniert zumindest, wenn man sich die XML Datei in einem Browser anzeigen läßt. Ob es dein Problem behebt weiß ich nicht.

[atomicbunny]

Also war die (nicht vorhandene) automatische Nummerierung der Spalten der Grund, warum nur ein Artikel importiert wurde?

Das mit latin1 sehe ich auch gerade. Wieso wird die DB in utf-8 angelegt und die Spalten sind in latin1? Ich möchte eigentlich schon alles in utf-8 haben.

Ich hab mit

UPDATE oxarticles SET OXPRICE=(OXPRICE/100)

Dezimalpunkte in der Spalte Preise eingefügt. Mir fehlte dort der Dezimalpunkt (der in den originalen XML Dateien auch nicht da war). Also in der DB stand „995“, aber es muss „9.95“ sei. War das ok oder macht man das normalerweise mit einer anderen Funktion?


Viele Grüße

Mario

[urvater]

Die Datentypen DECIMAL und NUMERIC werden zur Speicherung exakter numerischer Datenwerte verwendet. In MySQL ist NUMERIC als DECIMAL implementiert. Diese Typen werden zur Speicherung von Werten benutzt, bei denen die Beibehaltung der exakten Genauigkeit entscheidend ist (z. B. bei Finanzberechnungen).

MySQL 5.1 speichert DECIMAL- und NUMERIC-Werte im binären Format. In älteren Versionen erfolgte die Speicherung als Strings. Siehe auch Kapitel 23, Präzisionsberechnungen.

Wenn Sie eine DECIMAL- oder NUMERIC-Spalte deklarieren, können (und sollten) Genauigkeit und Anzahl der Nachkommastellen angegeben werden. Zum Beispiel:

salary DECIMAL(5,2)

Es könnte in der alten DB also die Spalte auf DEZIMAL gesetzt worden sein.

Also war die (nicht vorhandene) automatische Nummerierung der Spalten der Grund, warum nur ein Artikel importiert wurde?

Nein, es ist nicht zwingend ein auto_incement Wert in eine Tabelle erforderlich. Es wäre allerdings möglich, daß einer der Werte, die du einfügen wolltest den gleichen INDEX verwenden wollte.
Theoretisch sollte dies auf einen Fehler laufen.
Hattest du die Fehlerausgabe entsprechend angepasst?

Das mit latin1 sehe ich auch gerade. Wieso wird die DB in utf-8 angelegt und die Spalten sind in latin1? Ich möchte eigentlich schon alles in utf-8 haben.

Die DB ist eine Sache. Die Tabelle müsste entsprechend beim Erstellen auch als UTF-8 gesetzt werden. PHPAdmin verwendet sonst gern einmal den systemseitigen Zeichensatz (vom Client).
Ein nachträgliches Ändern des Zeichensatzes für die Textfelder behebt allerdings nicht dein Problem bei den schon vorhandenen Datensätzen.

[atomicbunny]

In der alten DB waren alle Artikeldaten ja in der XML Datei. Und diese war in der Tabelle „content“ und im Feld „body“ (longblob). In der neuen steht das Feld auf double.

Das Umlautproblem konnte ich mit

mysql_query("SET NAMES 'utf8'");

lösen.

Viele Grüße


Mario