mysql: Datamigration 4.0.23 -> 5.0.18

[Antman]

Hallo Forum,

ich habe die Tabellen der mysql 4.0.23 Installation exportiert und importieren sie gerade nach mysql 5.0.

Bei vielen Text Sätzen sagt der mir, dass der Datensatz zu lang sei.
Was soll das? Was hat sich da geändert und wie löst man das?

#1406 - Data too long for column 'produktbeschreibung' at row 1

Wieso sollen die Produktbeschreibungen auf einmal zu lang sein in mysql 5.0? Was hat sich da geändert und wie behebt man das Problem?

[Vinzenz Mai]

Hallo Antman,

ich habe die Tabellen der mysql 4.0.23 Installation exportiert und importieren sie gerade nach mysql 5.0.18
#1406 - Data too long for column 'produktbeschreibung' at row 1

Wieso sollen die Produktbeschreibungen auf einmal zu lang sein in mysql 5.0? Was hat sich da geändert und wie behebt man das Problem?

wie wäre es, wenn Du uns mitteilst, welchen Datentyp Du für diese Spalte verwendet hast, bisher und jetzt, zusätzlich welcher Inhalt zu lang ist.

Freundliche Grüße

Vinzenz

[Antman]

wie wäre es, wenn Du uns mitteilst, welchen Datentyp Du für diese Spalte verwendet hast, bisher und jetzt, zusätzlich welcher Inhalt zu lang ist.

Der Datentyp ist "text". Der Inhalt bei den Produktbeschreibungen ist zu lang. Wie gesagt. Ich habe Struktur und Daten exportiert.
Warum ist das auf einmal zu land?

[Vinzenz Mai]

Hallo Antman,

wie wäre es, wenn Du uns mitteilst, welchen Datentyp Du für diese Spalte verwendet hast, bisher und jetzt, zusätzlich welcher Inhalt zu lang ist.

Der Datentyp ist "text".

Hört sich danach an, als verwendete Dein MySQL 5.0.18 den strict SQL mode und der Inhalt sei zu lang für die Spalte.

Der Inhalt bei den Produktbeschreibungen ist zu lang. Wie gesagt. Ich habe Struktur und Daten exportiert.

Es könnte am Speicherbedarf liegen. Spalten vom Typ TEXT können 65533 Bytes enthalten, wenn ich richtig gerechnet habe, siehe http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html. Dies ist nicht mit 65533 Zeichen gleichzusetzen.

Könntest Du bitte das CREATE-Statement für Deine Tabelle posten und die Länge der angemeckerten Produktbeschreibung in Zeichen. Du hast noch überhaupt keine Informationen zum Inhalt abgeliefert. Wie sollten wir Dir sagen können, warum dieser uns unbekannte Inhalt zu lang sei?

Freundliche Grüße

Vinzenz

[Antman]

Also hier ist schon mal das CREATE Statement:

-- phpMyAdmin SQL Dump
-- version 2.7.0-pl2
-- http://www.phpmyadmin.net

[Antman]

Hier ist der Fehler der kommt:

SQL-Befehl:

INSERT INTO productinfo
VALUES (
'fr', 33, 'La nouvelle g�n�ration des rev�tements pour m�tal pr�cieux, � liant phosphate, exempt de graphite, destin� � la coul�e de tous les alliages pr� cieux ou non-pr�cieux pour la confection des couronnes et des bridges.\r\n', '', ''
);

MySQL meldet: Dokumentation
#1406 - Data too long for column 'produktbeschreibung' at row 1

[Vinzenz Mai]

Hallo

Meine MySQL-5.0.16-Installation schluckt Dein INSERT-Statement, allerdings habe ich nicht die Originaldaten, bei mir sind viele quadratische Kästchen dabei.

Übrigens brauchst Du die Länge von Einträgen nicht zu zählen, die String-Funktionen von MySQL helfen Dir dabei. Beachte z.B. die Unterschiede zwischen LENGTH() und CHAR_LENGTH(). Aber wenn Dein Beispiel authentisch ist, müsste der Fehler anderswo liegen.

Hast Du schon einmal versucht, das beanstandete INSERT-Statement über den MySQL-Query-Browser ausführen zu lassen?

Freundliche Grüße

Vinzenz

[Antman]

Habe den Query Broswer heruntergeladen.
Was gibt man im "Connection Dialog" als "Default Schema" an?

[Vinzenz Mai]

Hallo

Habe den Query Broswer heruntergeladen.
Was gibt man im "Connection Dialog" als "Default Schema" an?

typischerweise, wenn auch nicht immer, der Name der Datenbank, mit der Du bevorzugt arbeitest. Siehe dazu Wikipedia, Datenbankschema. Du kannst dieses Feld auch leer lassen.

Freundliche Grüße

Vinzenz

[Antman]

Versuche gerade über die "Skript Ausführen" Option meine Skripte zu importieren. Der impotiert sie zwar, gibt mir aber die Meldung Error 1062 bei allen importierten Artikeln. Der primary key ist die Artikelnummer.

Beipspiel:

INSERT INTO bestellinfo VALUES (37073, 1, 100, '#', 139, 139, 139, 139);

Die Artikelnummern kommen garantiert nicht doppelt vor, trotzdem gibt er im unteren Fenster für jede Artikelnummer aus "Duplicate entry for key 1".

Was soll das?

[Antman]

Dieses gibt er mir bei jeder Tabelle aus, wie ich gerade bemerkte. Trotzdem importiert er sie. Hmmm

Merkwürdig.

[dedlfix]

echo $begrüßung;

ich habe die Tabellen der mysql 4.0.23 Installation exportiert und importieren sie gerade nach mysql 5.0.

Du überspringst hier die Versionsnummer 4.1 in der wesentliche Veränderungen bei den unterstützten Zeichensätzen und beim Zeichensatzhandling vorgenommen wurden. Dieses Versionsüberspringen wird vom MySQL-Handbuch nicht empfohlen. Siehe dazu: Upgrading MySQL.
Vermutlich hast du dir auch nicht die Kapitel

• Upgrading from MySQL 4.0 to 4.1
• Upgrading from MySQL 4.1 to 5.0
• (Upgrading the Grant Tables)
• Character Set Support
  durchgelesen.

Welche Zeichenkodierung ist den im System (und Datenbank und Tabelle und Zellen) eingestellt?
Stellst du eine Zeichenkodierung für die aktuelle Verbindung ein (SET NAMES...)?
In welcher Kodierung liegen deine exportierten Daten vor? Vermutlich ist das eine andere (z.B. Latin1) als die Default-Einstellung des Systems (z.B. UTF-8).

echo "$verabschiedung $name";

[Antman]

Alles ist in UTF-8 gespeichert.
Was mache ich nun? Habe nur noch die SQL Dumps.

[dedlfix]

echo $begrüßung;

Alles ist in UTF-8 gespeichert.
Was mache ich nun? Habe nur noch die SQL Dumps.

Meinst du mit "Alles"? Deinen SQL-Dump? Wenn ja, wie kommt der in das UTF-8-Format? Ein Tool von MySQL 4.0 war das bestimmt nicht.
Oder waren die Daten vielleicht UTF-8-kodiert in der Datenbank eingetragen, mit dem Wissen dass MySQL 4.0 das zwar nicht direkt unterstützt aber auch keine Probleme macht, wenn die Daten einfach nur abgelegt und abgefragt werden (also ohne String-Funktionen beim Abfragen zu verwenden)?

echo "$verabschiedung $name";

[Antman]

Ja, ich habe die UTF 8 kodiert mittels phpmyadmin in der DB eingetragen. Und in phpmyadmin die Anzeige auf UTF 8 gestellt.

[dedlfix]

echo $begrüßung;

Ja, ich habe die UTF 8 kodiert mittels phpmyadmin in der DB eingetragen. Und in phpmyadmin die Anzeige auf UTF 8 gestellt.

Wann wurden sie gemäß UTF-8 kodiert? Damals beim Eintragen in Version 4.0? Oder versuchst du die, wie ich vermute, Latin1-kodierten Dump-Daten per phpMyAdmin zu importieren und hast dabei angegeben, dass die Daten UTF-8 wären?

Wenn das noch nicht des Rätsels Lösung ist, du also nicht beim Importieren der Daten über ein auf Latin1 gestelltes phpMyAdmin (das muss nur im Import-Dialog ausgewählt werden) zum Ziele kommst, wäre es schön, wenn du deine ausgeführten Schritte möglichst genau angibst.

echo "$verabschiedung $name";

[Antman]

Hallo,

Wann wurden sie gemäß UTF-8 kodiert? Damals beim Eintragen in Version 4.0? Oder versuchst du die, wie ich vermute, Latin1-kodierten Dump-Daten per phpMyAdmin zu importieren und hast dabei angegeben, dass die Daten UTF-8 wären?

Habe sie damals mit einem Unicode Editor UTF-8 kodiert über PHPmyadmin in mysql 4.0.18 gespeichert.

[Antman]

Das Problem ist nun, dass sie nach dem Reimport in die mysql 5.0 auf der Homepage Schrott kommt. Also nicht die einwandfreien texte und Daten sondern aus den SOnderzeichen werden Kästchen.

[dedlfix]

echo $begrüßung;

Das Problem ist nun, dass sie nach dem Reimport in die mysql 5.0 auf der Homepage Schrott kommt. Also nicht die einwandfreien texte und Daten sondern aus den SOnderzeichen werden Kästchen.

Dann vermute ich, dass ein Fehler bei der Konvertierung in dem Unicode-Editor aufgetreten ist. Wenn du diese Dump-Datei mal in einem Browser öffnest und die Zeichenkodierung änderst, kannst du da eine finden, bei der die Daten so aussehen, wie sie sollen? Wenn nicht, dann sehe ich schwarz, denn das was du in diesem Posting gepostet hast, sieht schon ziemlich verkorkst aus (wobei hier auch noch Übertragungsfehler beim Einfügen ins Forum aufgetreten sein können).

Ein weiterer Versuch wäre mal, eine beanstandete Zeile in eine neue Datei zu kopieren, die kaputten Sonderzeichen mit einem UTF-8-fähigen Editor zu korrigieren, und dann diese Datei probeweise zu importieren.

echo "$verabschiedung $name";

[Antman]

Hallo,

ja was ich da gepostet hatte war eine Ausnahme. Das waren noch Daten die eigentlich garnicht mehr in der DB hätten sein dürfen. Datenleichen!

Nein, nein. Ist schon alles UTF-8 kodiert. Wird auch alles richtig auf meinen html und in FLASH richtig angezeigt.

Im phpmyadmin ist die Sprache auf utf-8-de eingestellt.
Nun steht dort aber bei den Daten Müll. Also bei den Umlauten. Das war in der 4.0 Version nicht so.

Wenn ich in phpmyadmin aber ein Ü eingebe ist die Ausgabe in Flash wieder Müll. Man ist das verwirrend. Wo liegt nun das Problem.
Hat jahrelang wunderbar geklappt. Alles in meiner DB ist in UTF-8 gespeichert. SO konnte ich auch wunderbar griechisch, spanische, etc in  phpmyadmin lesen und schreiben.

Was mache ich nun?

[Antman]

Wenn ich mit dem Programm Query Browser ein Skript(das ich aus der 4.0 exportiert hatte) als utf-8 öffne und dann ausführe und dann sieht es im phpmyadmin ok aus. Die Umlaute werden ok angezeigt.

Dafür bekomme ich im Flash Programm aber Müll angzeigt.

Wenn ich das Skript im Query Browser im Ansi Modus öffne und ausführe und dann im phpmyadmin nachschaue, dann sind dort die Sonderzeichen Müll aber auf der UTF-8 Webseite sieht es OK aus.

Dreh bald durch.

[dedlfix]

echo $begrüßung;

Wenn ich mit dem Programm Query Browser ein Skript(das ich aus der 4.0 exportiert hatte) als utf-8 öffne und dann ausführe und dann sieht es im phpmyadmin ok aus. Die Umlaute werden ok angezeigt.

Dafür bekomme ich im Flash Programm aber Müll angzeigt.

Ich kenne mich mit Flash nicht aus und kann nur vermuten, dass entweder Flash nicht mit UTF-8 umgehen kann, oder du ihm explizit mitteilen musst, dass nun UTF-8-Daten kommen, es sonst ISO-8859-1-Daten erwartet. Wenn letzteres der Fall ist könntest du versuchen die Daten in ISO-8859-1 umzuwandeln, was aber nicht mit allen Zeichen verlustfrei möglich ist.

echo "$verabschiedung $name";