Board index Generelles in Deutsch WICHTIG: Umzug funktioniert nicht

Hier können Probleme und alles andere in Deutscher Sprache gelöst werden.
HadleyB
Regular
 
Posts: 738
Joined: Sun Feb 12, 2006 12:47 am

Postby HadleyB » Mon Sep 18, 2006 4:50 pm

Ich bin so vorgegangen:

Auf neuem Webspace Serendipity installiert mit neuer Datenbank. Dann komplett das "alte" Serendipity vom "alten" Account geholt und über den neuen drübergeschrieben.

Nun die "alte" Datenbank exportiert ohne bei den Einstellungen irgendwas angeklickt zu haben und den Dump versucht in die neue Datenbank zu schreiben.

Code: Select all
SQL-Befehl:

-- phpMyAdmin SQL Dump
-- version 2.6.4-pl3
-- http://www.phpmyadmin.net
--
-- Host: db95.puretec.de
-- Erstellungszeit: 18. September 2006 um 16:48
-- Server Version: 4.0.27
-- PHP-Version: 4.3.10-200.schlund.1
--
-- Datenbank: `db167991491`
--
CREATE DATABASE `db167991491` ;

MySQL meldet: Dokumentation
#1044 - Access denied for user '20060616005-2'@'213.160.81.6' to database 'db167991491'


Will heißen, er nimmt die Daten nicht an. Was mache ich denn falsch? Wenn ich das Blog nicht sichern kann, das ist doch irgendwie doof.

mfg
Hadley

stm999999999
Regular
 
Posts: 1517
Joined: Wed Mar 08, 2006 12:25 am
Location: Berlin, Germany

Postby stm999999999 » Mon Sep 18, 2006 6:31 pm

Code: Select all
CREATE DATABASE `db167991491` ;

MySQL meldet: Dokumentation
#1044 - Access denied for user '20060616005-2'@'213.160.81.6' to database 'db167991491'


Bist Du Dir sicher, daß Du auf dem neuen Space selber Datenbanken anlegen darfst? Und zwar insbesondere direkt per sql?
Ciao, Stephan

HadleyB
Regular
 
Posts: 738
Joined: Sun Feb 12, 2006 12:47 am

Postby HadleyB » Mon Sep 18, 2006 10:53 pm

stm999999999 wrote:
Code: Select all
CREATE DATABASE `db167991491` ;

MySQL meldet: Dokumentation
#1044 - Access denied for user '20060616005-2'@'213.160.81.6' to database 'db167991491'


Bist Du Dir sicher, daß Du auf dem neuen Space selber Datenbanken anlegen darfst? Und zwar insbesondere direkt per sql?

Ähem, ich habe keine Ahnung. Ich habe jetzt mal versucht, die einzelnen Tabellen der Datenbank separat rüberzukopieren aber bei der Tabelle Permalinks steigt er aus weiler sagt, die Länge würde überschritten.

Es funktioniert einfach nicht, sollte es aber. Hat denn keiner eine Anleitung auf Deutsch, wie man seinen BLOG sichert? Wenn's die Datenbank zersemmelt, dann ist die ganze Arbeit umsonst.

User avatar
garvinhicking
Core Developer
 
Posts: 29974
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany

Postby garvinhicking » Mon Sep 18, 2006 11:00 pm

Hi!

Was genau sagt er bei "Länge überschritten"? Evtl. musst du deinen SQL-Dump in kleinere Teile und mit "extended inserts" exportieren?

Grßüe,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/

HadleyB
Regular
 
Posts: 738
Joined: Sun Feb 12, 2006 12:47 am

Postby HadleyB » Wed Sep 20, 2006 7:36 am

garvinhicking wrote:Hi!

Was genau sagt er bei "Länge überschritten"? Evtl. musst du deinen SQL-Dump in kleinere Teile und mit "extended inserts" exportieren?

Grßüe,
Garvin

Er bricht immer bei den Permalinks ab:

SQL-Befehl:

-- --------------------------------------------------------
--
-- Tabellenstruktur f�r Tabelle `serendipity_permalinks` --
CREATE TABLE `sere ndipity_permalinks ` ( `perm alink ` var char( 255 ) NOT NULL default '', `entr y_id ` int ( 10 ) unsigned NOT NULL default '0', `type ` var char( 200 ) NOT NULL default '', `data ` tex t,
KEY `pl_i dx ` (`p ermalink `), KEY `ple_ idx ` (`e ntry_id `), KEY `plt_ idx ` (`t ype `), KEY `plco mb_idx ` (`p ermalink `,`ty pe `) ) TYPE = MYISAM ;

MySQL meldet: Dokumentation
#1071 - Specified key was too long; max key length is 1000 bytes


Selbst wenn ich die Tabelle der Permalinks leermache, kommt diese Fehlermeldung. Doch auch das ist noch nicht alles, er mag auch die Tabelle PLUGINCATEGORIES nicht:

Code: Select all
Fehler
Möglicherweise haben Sie einen Bug im SQL-Parser entdeckt. Bitte überprüfen Sie Ihre Abfrage genaustens, insbesondere auf falsch gesetzte oder nicht geschlossene Anführungszeichen. Eine weitere Ursache könnte darin liegen, dass Sie versuchen eine Datei mit binären Daten, welche nicht von Anführungszeichen eingeschlossen sind, hochzuladen. Sie können alternativ versuchen Ihre Abfrage über das MySQL-Kommandozeileninterface zu senden. Die MySQL-Fehlerausgabe, falls vorhanden, kann Ihnen auch bei der Fehleranalyse helfen. Falls Sie weiterhin Probleme haben sollten oder der Parser dort versagt, wo die Kommandozeile erfolgreich ist, so reduzieren Sie bitte Ihre Abfrage auf den Befehl, welcher die Probleme verursacht, und senden Sie uns einen Bugreport mit den Datenausschnitt, den Sie weiter unten auf dieser Seite finden.:
----AUSSCHNITTSANFANG----
eNqdkEFPwkAQhe/7K97BgyRtbYsIrvFQcaPELWBbMXihBRZoXNvabg397x5cwKgnTZxkTvPefG+G
BcEooOg76LvgbEjhtHu6z9Hu2iSM9Oy9RJTMCelPQoqjwZKiepVFUlaitGQ6t4pNYbzBtU67cG37
7MR2TpwunC61Xdq2sWjmuZqpF7BtgSPiN+E9pzi1HMt1TJmvyUMYYBQa8G7YMDIwYZr5mGbwR08D
zj10LJuMfY9qRM9yyfh2vNMYI52mo7ecmYV0zbXIVJ6Dp1m9Jdwb3lAshVmrldkjeyAhpoldXydK
ZFgdrhJSCsT6EpEt0yJVzazY5Cqf61zx3rC3mf+sL+YnKatUWT+ruvwFL+t1mi10xnVepqL6TNEP
mBcxRN4VZ38YcEyAeCGTqpplyYuI8ZaUi01SHrsdu6W/skpqqTB84NzYKw/W5g/dHZsi/oLN0uVW
k35ijO9NLdJCNB2zS78ZhJ5/8QGLFrPn
----AUSSCHNITTSENDE----
----BEGINN DER AUSGABE----

ERROR: C1 C2 LEN: 138 139 370
STR: �r Tab

CVS: $Id: sqlparser.lib.php,v 2.47 2006/01/17 17:02:30 cybot_tm Exp $
MySQL: 4.1.21-log
USR OS, AGENT, VER: Win MOZILLA 5.0
PMA: 2.8.2
PHP VER,OS: 5.1.6-pl2-gentoo Linux
LANG: de-utf-8
SQL:

--
-- Daten f�r Tabelle `serendipity_photoblog`
--


-- --------------------------------------------------------

--
-- Tabellenstruktur f�r Tabelle `serendipity_plugincategories`
--

CREATE TABLE `serendipity_plugincategories` (
  `class_name` varchar(250) default NULL,
  `category` varchar(250) default NULL,
  KEY `plugincat_idx` (`class_name`,`category`)
) TYPE=MyISAM;

----ENDE DER AUSGABE----

SQL-Befehl:

-- -- Daten f�r Tabelle `serendipity_photoblog` -- -- -------------------------------------------------------- -- -- Tabellenstruktur f�r Tabelle `serendipity_plugincategories` -- CREATE TABLE `serendipity_plugincategories` ( `class_name` varchar(250) default NULL, `category` varchar(250) default NULL, KEY `plugincat_idx` (`class_name`,`category`) ) TYPE=MyISAM;

MySQL meldet: Dokumentation
#1071 - Specified key was too long; max key length is 1000 bytes


mfg
Hadley[/code]

User avatar
garvinhicking
Core Developer
 
Posts: 29974
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany

Postby garvinhicking » Wed Sep 20, 2006 10:42 am

Hi!

Argh, der MySQL key length fehler.

Anscheinend wird dein MySQL mit UTF-16 betrieben, was die Länge der Keys vervierfacht. Du müsstest es irgendwie hinkriegen, die MySQL-Tabellen nur mit UTF-8 zu betreiben. Alternativ müsste man die Indize/Keys aller Tabellen so umändern, dass bei jedem Key eine Zeichenbeschränkung eingetragen wird die zusammen addiert maximal 250 Zeichen (250 * 4 = 1000) betragen dürfen.

Grüße,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/

HadleyB
Regular
 
Posts: 738
Joined: Sun Feb 12, 2006 12:47 am

Postby HadleyB » Wed Sep 20, 2006 11:02 am

garvinhicking wrote:Hi!

Argh, der MySQL key length fehler.

Anscheinend wird dein MySQL mit UTF-16 betrieben, was die Länge der Keys vervierfacht. Du müsstest es irgendwie hinkriegen, die MySQL-Tabellen nur mit UTF-8 zu betreiben. Alternativ müsste man die Indize/Keys aller Tabellen so umändern, dass bei jedem Key eine Zeichenbeschränkung eingetragen wird die zusammen addiert maximal 250 Zeichen (250 * 4 = 1000) betragen dürfen.

Grüße,
Garvin

Ganz ehrlich? Das ist mir viel zu hoch. Ich habe nicht ein einziges Wort verstanden. Wenn ich die Codierung der Tabellen ändere, dann zerhaut es doch mit Sicherheit das gesammte Blog.

mfg
Hadley

User avatar
garvinhicking
Core Developer
 
Posts: 29974
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany

Postby garvinhicking » Wed Sep 20, 2006 11:05 am

Hi!

Ich würde dir helfen, muss jetzt aber offline und endlich in Urlaub - evtl. kann dir jemand anders mit SQL Kenntnissen da helfen.

Änderungen von UTF-16 auf UTF-8 sollten eigentlich kein Problem machen.

Viele Grüße,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/

HadleyB
Regular
 
Posts: 738
Joined: Sun Feb 12, 2006 12:47 am

Postby HadleyB » Wed Sep 20, 2006 12:39 pm

garvinhicking wrote:Hi!

Ich würde dir helfen, muss jetzt aber offline und endlich in Urlaub - evtl. kann dir jemand anders mit SQL Kenntnissen da helfen.

Änderungen von UTF-16 auf UTF-8 sollten eigentlich kein Problem machen.

Viele Grüße,
Garvin

Dann ab in den Urlaub. Du hast Dir den wirklich verdient!

mfg
Hadley

Boris
Regular
 
Posts: 93
Joined: Thu Mar 10, 2005 8:14 pm
Location: Germany

Postby Boris » Sun Jan 28, 2007 1:51 pm

Bin gerade auf das gleiche Problem gestossen.

garvinhicking wrote:maximal 250 Zeichen (250 * 4 = 1000)

Lustigerweise sind es genau 333 erlaubte Zeichen bei mir.

Ich hab mir damit beholfen, dass ich nur die ersten 78 Zeichen von type als Schluessel betrachte. Momemtan ist die maximale Länge nur 8, hoffe mal das ändert sich nicht signifikant. Ansonsten dürfen halt zwei verschiedene Typen nicht den gleichen Permalink haben ;-)

Code: Select all
KEY `plcomb_idx` (`permalink`,`type`(78))

User avatar
Zugschlus
Regular
 
Posts: 106
Joined: Sun Feb 05, 2006 1:54 am
Location: St. Ilgen, Germany

Postby Zugschlus » Thu Aug 03, 2017 5:54 pm

Ich habe dieses Problem jetzt auch beim Import eines Datenbankdumps. Ich habe Debian stretch mit MariaDB 10.1.

phpMyAdmin sagt "Server charset: UTF-8 Unicode (utf8)", die Datenbank steht auf "Collation: utf8_unicode_ci" und die Definition der Tabelle serendipity_permalinks sagt "CHARSET=utf8".

Laut https://dev.mysql.com/doc/refman/5.7/en ... -utf8.html wird ein UTF-8 Zeichen von MySQL wie drei Zeichen gewertet, und (200 + 255 ) * 3 ist > 1000. Meine Hypothese wird bestätigt, dass man (200 + 133) * 3 = 999 noch anlegen kann, (200 + 134 ) * 3 = 1002 lässt sich nicht mehr anlegen.

Diese Tabelle dürfte also nicht in UTF8 angelegt werden oder die Werte müssen kürzer. Warum ist "type" überhaupt 200 Bytes lang? Dasselbe Problem gibt es bei serendipity_plugincategories mit zweimal 250 bytes.

Grüße
Marc
--
Marc Haber, St. Ilgen, Germany
http://blog.zugschlus.de/

User avatar
garvinhicking
Core Developer
 
Posts: 29974
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany

Postby garvinhicking » Thu Sep 14, 2017 12:43 pm

Hi!

Wir haben einen utf8-migration Github branch, wo ich versucht habe alle Keys für utf8mb4 kompatibel zu machen:

https://github.com/s9y/Serendipity/tree/feature_utf8mb4

Da am besten mal in die sql/db.sql reinschauen. Eigentlich müsste der Upgrader wenn man jene Version installiert die Datenbank mit anpassen bzw. die notwendigen SQL-Statements dazu auch ausgeben über einen Migration-Task. Das könntest du mit einer Kopie oder so mal gerne ausprobieren, denn ich habe quasi noch kein Feedback zu dem Feature dort bekommen und würde mich über welches freuen :)

LG,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/



Return to Generelles in Deutsch

Who is online

Users browsing this forum: No registered users and 3 guests