Datenbank importieren

Hallo zusammen,

versuch ein Jooml 1.0 Datenbank MySQL DB 4.0.24 auf MySQL-Client-Version: 5.0.30 zu portieren.

Bei phpMyAdmin - 2.9.1.1-Debian-1 bekomme ich folgende Meldung:

Fehler

SQL-Befehl:

--
-- Table structure for table `jos_content`
--
CREATE TABLE jos_content(
id int( 11 ) unsigned NOT NULL AUTO_INCREMENT ,
title varchar( 100 ) NOT NULL default '',
title_alias varchar( 100 ) NOT NULL default '',
introtext mediumtext NOT NULL ,
FULLTEXT mediumtext NOT NULL ,
state tinyint( 3 ) NOT NULL default '0',
sectionid int( 11 ) unsigned NOT NULL default '0',
mask int( 11 ) unsigned NOT NULL default '0',
catid int( 11 ) unsigned NOT NULL default '0',
created datetime NOT NULL default '0000-00-00 00:00:00',
created_by int( 11 ) unsigned NOT NULL default '0',
created_by_alias varchar( 100 ) NOT NULL default '',
modified datetime NOT NULL default '0000-00-00 00:00:00',
modified_by int( 11 ) unsigned NOT NULL default '0',
checked_out int( 11 ) unsigned NOT NULL default '0',
checked_out_time datetime NOT NULL default '0000-00-00 00:00:00',
publish_up datetime NOT NULL default '0000-00-00 00:00:00',
publish_down datetime NOT NULL default '0000-00-00 00:00:00',
images text NOT NULL ,
urls text NOT NULL ,
attribs text NOT NULL ,
version int( 11 ) unsigned NOT NULL default '1',
parentid int( 11 ) unsigned NOT NULL default '0',
ordering int( 11 ) NOT NULL default '0',
metakey text NOT NULL ,
metadesc text NOT NULL ,
access int( 11 ) unsigned NOT NULL default '0',
hits int( 11 ) unsigned NOT NULL default '0',
PRIMARY KEY ( id ) ,
KEY idx_section( sectionid ) ,
KEY idx_access( access ) ,
KEY idx_checkout( checked_out ) ,
KEY idx_state( state ) ,
KEY idx_catid( catid ) ,
KEY idx_mask( mask )
) TYPE = MYISAM ;

MySQL meldet: Dokumentation
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the
right syntax to use near 'mediumtext NOT NULL,
state tinyint(3) NOT NULL default '0',
sectionid int(11' at line 6


Die Meldung besagt so viel "Ich habe einen Fehler im Syntax, checke die Übereistimmung in den Server versionen, die
Stelle ist 'mediumtext NOT NULL, ".

Beim Import der Datenbank über phpMyAdmin habe ich "SQL-Kompatibilitätsmodus" "MYSQL40" gewählt, leider hat es nicht
geholfen.

Wie kann ich den Fehler beheben?

Fehlt etwa in den Zeilen:
....
introtext mediumtext NOT NULL ,
FULLTEXT mediumtext NOT NULL ,
....
nach NOT NULL ''<--- ?


Grüße bernhard

Re: Datenbank importieren

Am 20.08.2007 15:55 schrieb bernhard.s:
> Hallo zusammen,
>
> versuch ein Jooml 1.0 Datenbank MySQL DB 4.0.24 auf MySQL-Client-Version: 5.0.30 zu portieren.
>
> Bei phpMyAdmin - 2.9.1.1-Debian-1 bekomme ich folgende Meldung:
>

PHPMyAdmin ist hier aus guten Gründen nicht OT. Bitte benutze die von
MySQL gelieferten Werkzeuge (in dem Fall mysqldump und mysql) für
Deine Zwecke.

Benutze Google, um Dich über die Schwierigkeiten bei der Migration von
4.x auf 5.x mittels PHPMyAdmin zu informieren.

> FULLTEXT mediumtext NOT NULL ,

FULLTEXT dürfte inzwischen ein reserviertes Wort sein.

>
> MySQL meldet: Dokumentation
> #1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the
> right syntax to use near 'mediumtext NOT NULL,
> state tinyint(3) NOT NULL default '0',
> sectionid int(11' at line 6
>
>
> Die Meldung besagt so viel "Ich habe einen Fehler im Syntax, checke die Übereistimmung in den Server versionen, die
> Stelle ist 'mediumtext NOT NULL, ".
>

Typisch für MySQL: Der Fehler ist immer *direkt* vor dieser Stelle.
Und in diesem Fall trivial.

> Beim Import der Datenbank über phpMyAdmin habe ich "SQL-Kompatibilitätsmodus" "MYSQL40" gewählt, leider hat es nicht
> geholfen.
>
> Wie kann ich den Fehler beheben?
>
> Fehlt etwa in den Zeilen:
> ...
> introtext mediumtext NOT NULL ,
> FULLTEXT mediumtext NOT NULL ,

Handbuch gelesen?

--
Christian

Re: Datenbank importieren

Am Mon, 20 Aug 2007 15:55:46 +0200 schrieb bernhard.s:
> FULLTEXT mediumtext NOT NULL ,

http://www.mysql.org/doc/refman/5.0/en/reserved-words.html

Norbert

Re: Datenbank importieren

Christian Kirsch schrieb:

> Am 20.08.2007 15:55 schrieb bernhard.s:

Voller Realname wäre nett ...

> Typisch für MySQL: Der Fehler ist immer *direkt* vor dieser Stelle.

Ich weiß ja nicht, welches MySQL Du benutzt, aber mein MySQL meldet den
Fehler immer genau an der Stelle, an der er ist.

Allerdings kann MySQL nur syntaktische Fehler erkennen, nicht aber
logische. Die muss man dann schon selber finden. Das ist aber nicht
"Typisch für MySQL", sondern gilt für _alle_ Interpreten, Compiler etc.

Gruß. Claus

Re: Datenbank importieren

Hallo zusammen,

bin dem Fehler auf die Spur gekommen, es sind die reservierten Wörter
http://www.mysql.org/doc/refman/5.1/de/reserved-words.html die das ganze scheitern lassen haben.

Habe das Problem folgender Maßen gelöst key_word --> `key_word` ins Akut-Zeichen gesetzt.
Wahrscheinlich nicht die feine Lösung aber es funktioniert.


Ein Problem gelöst, das nächste ist aufgetreten:

ERROR 1071 (42000) at line 58092: Specified key was too long; max key length is 1000 bytes

CREATE TABLE serendipity_permalinks ( #<---------------- 58092
permalink varchar(255) NOT NULL default '',
entry_id int(10) unsigned NOT NULL default '0',
type varchar(200) NOT NULL default '',
data text,
KEY pl_idx (permalink),
KEY ple_idx (entry_id),
KEY plt_idx (type),
KEY plcomb_idx (permalink,type)
) TYPE=MyISAM;

Ein der Datentypen stimmt nicht, vermute "unsigned".

Falls einer den Fehler sieht, bitte posten.

An diese Stelle Danke an alle die mir geantwortet haben.

Grüße Bernhard

Re: Datenbank importieren

Am 20.08.2007 23:12 schrieb Claus Reibenstein:
> Christian Kirsch schrieb:
>
>> Am 20.08.2007 15:55 schrieb bernhard.s:
>
> Voller Realname wäre nett ...
>
>> Typisch für MySQL: Der Fehler ist immer *direkt* vor dieser Stelle.
>
> Ich weiß ja nicht, welches MySQL Du benutzt, aber mein MySQL meldet den
> Fehler immer genau an der Stelle, an der er ist.
>

Dann zitiere ich doch extra für Dich noch mal aus dem OP:

> introtext mediumtext NOT NULL ,
> FULLTEXT mediumtext NOT NULL ,
> state tinyint( 3 ) NOT NULL default '0',
> sectionid int( 11 ) unsigned NOT NULL default '0',

....

> #1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the
> right syntax to use near 'mediumtext NOT NULL,

Der Fehler ist "FULLTEXT" - und damit genau *vor* dem, was MySQL
anmeckert. Der MySQL-Parser hat diese Macke schon seit Ewigkeiten.
Guck' Dir mal an, was ein Compiler macht, wenn Du ein reserviertes
Wort benutzt:

> main() {
> int if;
> }

> gcc -c bla.c
> bla.c: In function 'main':
> bla.c:2: error: expected identifier or '(' before 'if

MySQL würde in dieser Situation "Syntax error near "}" schreiben. Was
etwa so hilfreich ist wie "Syntax error in main()".


> Allerdings kann MySQL nur syntaktische Fehler erkennen,

Das *ist* ein syntaktischer Fehler. Die Syntax von MySQLs SQL-Dialekt
legt fest, welche Wörter reserviert und nicht ohne weiteres als
Spaltennamen zulässig sind. Ein reserviertes Wort als Spaltenname zu
verwenden, hat nichts mit der Semantik zu tun.

> nicht aber
> logische. Die muss man dann schon selber finden. Das ist aber nicht
> "Typisch für MySQL", sondern gilt für _alle_ Interpreten, Compiler etc.
>

Unsinn. Es *ist* ein syntaktischer Fehler. Das Gegenbeispiel bzgl.
"alle Compiler" steht oben. Außerdem behauptet ja auch MySQL selbst,
es handele sich um einen Syntax-Fehler (du könntest die zitierte
Fehlermeldung nochmal lesen).

Das Problem ist der Parser von MySQL, der zwar merkt, dass es einen
Fehler gibt, aber keine Lust hat, rückwärts zu gucken, wo denn dieser
Fehler genau herkommt.

--
Christian

Re: Datenbank importieren

Am 21.08.2007 09:12 schrieb Bernhard.Schimanski:
> Hallo zusammen,
>
> bin dem Fehler auf die Spur gekommen, es sind die reservierten Wörter
> http://www.mysql.org/doc/refman/5.1/de/reserved-words.html die das ganze scheitern lassen haben.
>
> Habe das Problem folgender Maßen gelöst key_word --> `key_word` ins Akut-Zeichen gesetzt.
> Wahrscheinlich nicht die feine Lösung aber es funktioniert.
>
>
> Ein Problem gelöst, das nächste ist aufgetreten:
>
> ERROR 1071 (42000) at line 58092: Specified key was too long; max key length is 1000 bytes

Das hatten wir hier neulich erst. Google Groups ist ein bewährtes
Mittel: Erst lesen, dann fragen.

>
> CREATE TABLE serendipity_permalinks ( #<---------------- 58092
> permalink varchar(255) NOT NULL default '',
> entry_id int(10) unsigned NOT NULL default '0',
> type varchar(200) NOT NULL default '',
> data text,
> KEY pl_idx (permalink),
> KEY ple_idx (entry_id),
> KEY plt_idx (type),
> KEY plcomb_idx (permalink,type)
> ) TYPE=MyISAM;
>

Hint: Dein Server/Deine DB/Deine Tabelle benutzt UTF-8 für alle
char/varchar-Spalten. Bist Du sicher, dass "permalink" und/oder "type"
(wieder so ein ungeschickter Spaltenname) wirklich UTF-8-Daten brauchen?

> Ein der Datentypen stimmt nicht, vermute "unsigned".

Was meinst Du mit "stimmt nicht"? Die Datentypen sind immer so, wie Du
sie angibst. Ob sie Deinen Anforderungen entsprechen, musst Du selber
entscheiden. Wenn unsigned in diesem Zusammenhang nicht zulässig wäre,
würde MySQL Dir das zwar sagen - aber vermutlich doch mit einer
*anderen* Fehlermeldung. Denn was sollte "max key length is 1000
bytes" mit einem 10 Byte großen Integer zu tun haben?


--
Christian

Re: Datenbank importieren

Christian Kirsch!

> Der Fehler ist "FULLTEXT" - und damit genau *vor* dem, was MySQL
> anmeckert. Der MySQL-Parser hat diese Macke schon seit Ewigkeiten.

Nein. Der Fehler ist "mediumtext NOT NULL". Bis inklusive FULLTEXT ist
das noch eine korrekte Spezifikation eines Volltextindexes. Das ist
jedenfalls die Auffassung von MySQL.

>> main() {
>> int if;
>> }

Demzufolge ist das auch kein passender Vergleich. An der Stelle ist
"if" gar nicht erlaubt, weil es ein Keyword ist.

>> gcc -c bla.c
>> bla.c: In function 'main':
>> bla.c:2: error: expected identifier or '(' before 'if

Und auch der gcc meldet den falschen Fehler. Du willst eine Variable vom
Typ int mit dem Namen if deklarieren; der gcc denkt, dass du den Namen
vergessen hast und das if irgendwas anderes ist.

Wenn du ihm den Gefallen tust und eine identifier einschiebst (int i if),
dann schlägt er u.a. ein Semikolon vor. Kein Wort davon, dass "if" an der
Stelle nicht erlaubt ist.

> Das *ist* ein syntaktischer Fehler. Die Syntax von MySQLs SQL-Dialekt
> legt fest, welche Wörter reserviert und nicht ohne weiteres als
> Spaltennamen zulässig sind. Ein reserviertes Wort als Spaltenname zu
> verwenden, hat nichts mit der Semantik zu tun.

Das ist aber, wie gesagt, nicht der Fehler. Dass FULLTEXT ein Spaltenname
sein soll, ist, ohne die Semantik zu verstehen, nicht zu erkennen.


Gruß
Daniel

Re: Datenbank importieren

Hallo,

Christian Kirsch schrieb:

>> ERROR 1071 (42000) at line 58092: Specified key was too long; max key length is 1000 bytes
>
> Das hatten wir hier neulich erst. Google Groups ist ein bewährtes
> Mittel: Erst lesen, dann fragen.

unter http://groups.google.de/groups habe ich bis jetzt nur gefunden, das einige Leute ähnliche Probleme haben

> Hint: Dein Server/Deine DB/Deine Tabelle benutzt UTF-8 für alle
> char/varchar-Spalten. Bist Du sicher, dass "permalink" und/oder "type"
> (wieder so ein ungeschickter Spaltenname) wirklich UTF-8-Daten brauchen?
Ja, es ist kein Schlüsselwort.

>
>> Ein der Datentypen stimmt nicht, vermute "unsigned".
Diese Vermutung war natürlich falsch :-(

>
> Was meinst Du mit "stimmt nicht"? Die Datentypen sind immer so, wie Du
> sie angibst. Ob sie Deinen Anforderungen entsprechen, musst Du selber
> entscheiden. Wenn unsigned in diesem Zusammenhang nicht zulässig wäre,
> würde MySQL Dir das zwar sagen - aber vermutlich doch mit einer
> *anderen* Fehlermeldung. Denn was sollte "max key length is 1000
> bytes" mit einem 10 Byte großen Integer zu tun haben?

Stimmt.

Den Fehler habe ich eingegrenzt:
....
(Ein älterer Standard für die UTF-8-Kodierung ist in RFC 2279 enthalten, wo UTF-8-Sequenzen mit einer Länge von bis zu 6
Byte beschrieben werden. RFC 3629 hat RFC 2279 ersetzt, weswegen Sequenzen mit 5 oder 6 Byte heute nicht mehr verwendet
werden.)
....
http://www.mysql.org/doc/refman/5.1/de/charset-unicode.html

Eine andere Erklärung, die ich im Netz gefunden habe:
Jedes UTF-8 Zeichen ist genauer betrachtet 3 Bytes lang. Indexe in MySQL können bis zu 1000 Byte lang sein (767 Byte bei
InnoDB-Tabellen). Beachten Sie, dass die Grenzen in Byte gemessen werden, im Gegensatz zu der Länge einer Spalte, die in
Anzahl von Zeichen interpretiert wird.

Das würde für mich heißen, dass ich beim anlegen der Tabelle, die Zeichen angaben begrenzen muss?

Grüße Bernhard

Re: Datenbank importieren

Am 21.08.2007 10:55 schrieb Daniel Fischer:
> Christian Kirsch!
>
>> Der Fehler ist "FULLTEXT" - und damit genau *vor* dem, was MySQL
>> anmeckert. Der MySQL-Parser hat diese Macke schon seit Ewigkeiten.
>
> Nein. Der Fehler ist "mediumtext NOT NULL". Bis inklusive FULLTEXT ist
> das noch eine korrekte Spezifikation eines Volltextindexes. Das ist
> jedenfalls die Auffassung von MySQL.

ACK. Es bleibt also bei meiner Daumenregel: Der Fehler ist immer genau
*vor* dem ersten Wort, das MySQL nicht gefällt. Und meine erste
Interpretation, "FULLTEXT" sei als Spaltenname nicht erlaubt, weil
eben Keyword, ist damit auch hinfällig.

>
>>> main() {
>>> int if;
>>> }
>
> Demzufolge ist das auch kein passender Vergleich. An der Stelle ist
> "if" gar nicht erlaubt, weil es ein Keyword ist.
>
>>> gcc -c bla.c
>>> bla.c: In function 'main':
>>> bla.c:2: error: expected identifier or '(' before 'if
>
> Und auch der gcc meldet den falschen Fehler. Du willst eine Variable vom
> Typ int mit dem Namen if deklarieren; der gcc denkt, dass du den Namen
> vergessen hast und das if irgendwas anderes ist.

Mag sein - aber er meldet einen *Kontext*, mit dem man was anfangen
kann - er sagt eben "before if", und nicht "mediumtext". Meine Kritik
am MySQL-Parser heißt ja, kurzgefasst, dass er eigentlich immer einen
Syntaxfehler meldet, der *hinter* dem eigentlichen liegt.

>
> Das ist aber, wie gesagt, nicht der Fehler. Dass FULLTEXT ein Spaltenname
> sein soll, ist, ohne die Semantik zu verstehen, nicht zu erkennen.
>

Jein. Eine *brauchbare* Fehlermeldung wäre z.B. "mediumtext not
allowed in FULLTEXT index definition". Das ist immer noch Syntax (denn
MySQL denkt ja, es handele sich um die Definition eines FULLTEXT
index), und es liefert hinreichend Kontext für denjenigen, der den
flaschen Code geschrieben hat.

--
Christian

Re: Datenbank importieren

Bernhard.Schimanski!

> Jedes UTF-8 Zeichen ist genauer betrachtet 3 Bytes lang. Indexe in MySQL
> können bis zu 1000 Byte lang sein (767 Byte bei InnoDB-Tabellen).
> Beachten Sie, dass die Grenzen in Byte gemessen werden, im Gegensatz zu
> der Länge einer Spalte, die in Anzahl von Zeichen interpretiert wird.

Ja.

> Das würde für mich heißen, dass ich beim anlegen der Tabelle, die
> Zeichen angaben begrenzen muss?

Das ist eine Möglichkeit.

Du könntest auch die Anzahl der Zeichen, über die ein Index erstellt
wird, begrenzen (KEY indexname (spaltenname(10)) etc.).

Eine Alternative ist, die entsprechenden Spalten eben nicht als UTF-8
abzulegen. Das war ja offenbar bisher auch nicht der Fall. Du kannst in
der Spaltenspezifikation z.B. "CHARACTER SET latin1" einfügen, wenn
latin1 deinen Anforderungen genügt. Oder du kannst gleich global latin1
als default einstellen, wenn du sicher weißt, dass du UTF-8 eh nicht
brauchst.


Gruß
Daniel

Re: Datenbank importieren

Am 21.08.2007 11:13 schrieb Bernhard.Schimanski:

> Christian Kirsch schrieb:

>> Hint: Dein Server/Deine DB/Deine Tabelle benutzt UTF-8 für alle
>> char/varchar-Spalten. Bist Du sicher, dass "permalink" und/oder "type"
>> (wieder so ein ungeschickter Spaltenname) wirklich UTF-8-Daten brauchen?
> Ja, es ist kein Schlüsselwort.
>

*Noch* nicht. Deshalb schrieb ich ja "ungeschickt". Auch "time" war
früher kein Schlüsselwort, IIRC. Die Frage, ob Du an dieser Stelle
UTF-8 brauchst, hast Du nicht beantwortet.

> Eine andere Erklärung, die ich im Netz gefunden habe:
> Jedes UTF-8 Zeichen ist genauer betrachtet 3 Bytes lang. Indexe in MySQL können bis zu 1000 Byte lang sein (767 Byte bei
> InnoDB-Tabellen). Beachten Sie, dass die Grenzen in Byte gemessen werden, im Gegensatz zu der Länge einer Spalte, die in
> Anzahl von Zeichen interpretiert wird.

Dein letzter Index hat 455 *Zeichen*, also muss MySQL bei UTF-8 das
Dreifache dafür reservieren.

>
> Das würde für mich heißen, dass ich beim anlegen der Tabelle, die Zeichen angaben begrenzen muss?

Dunkel ist Deiner Rede Sinn (übrigens ebenso wie der Sinn Deiner
Index-Definitionen - wozu brauchst Du einen Index auf permalink, wenn
Du einen auf (permalink,type) schon hast?). Was meinst Du mit "Zeichen
angaben"?

Wenn Du bisher ohne UTF-8 ausgekommen bist, könntest Du doch einfach
sicherstellen, dass die Tabellenspalten Latin-1 benutzen? Du könntest
natürlich auch statt der ganzen Spalten nur Teile indizieren. Oder
kürzere CHAR/VARCHAR-Felder benutzen.

--
Christian

Re: Datenbank importieren

Hallo,

erst Mal danke an alle.

Daniel Fischer schrieb:
> Bernhard.Schimanski!
>
>> Jedes UTF-8 Zeichen ist genauer betrachtet 3 Bytes lang. Indexe in MySQL
>> können bis zu 1000 Byte lang sein (767 Byte bei InnoDB-Tabellen).
>> Beachten Sie, dass die Grenzen in Byte gemessen werden, im Gegensatz zu
>> der Länge einer Spalte, die in Anzahl von Zeichen interpretiert wird.
>
> Ja.
>
>> Das würde für mich heißen, dass ich beim anlegen der Tabelle, die
>> Zeichen angaben begrenzen muss?
>
> Das ist eine Möglichkeit.
>
> Du könntest auch die Anzahl der Zeichen, über die ein Index erstellt
> wird, begrenzen (KEY indexname (spaltenname(10)) etc.).
Das habe ich auch getan.

>
> Eine Alternative ist, die entsprechenden Spalten eben nicht als UTF-8
> abzulegen. Das war ja offenbar bisher auch nicht der Fall. Du kannst in
> der Spaltenspezifikation z.B. "CHARACTER SET latin1" einfügen, wenn
> latin1 deinen Anforderungen genügt. Oder du kannst gleich global latin1
> als default einstellen, wenn du sicher weißt, dass du UTF-8 eh nicht
> brauchst.

Also es handelt sich um eine DB von Joomla 1.0 und Serendipity (http://www.s9y.org/) ein Blogsoftwre, wie die
Serendipity aufgebaut ist, kann ich nicht sagen.

>Dunkel ist Deiner Rede Sinn (übrigens ebenso wie der Sinn Deiner
>Index-Definitionen - wozu brauchst Du einen Index auf permalink, wenn
>Du einen auf (permalink,type) schon hast?). Was meinst Du mit "Zeichen
>angaben"?

Die Tabelle "serendipity_permalinks" ist ein Teil von Serendipity, wo die oben erwähnten Spalten verwendet werden, kann
ich ebenfalls nicht sagen. Die Serendipity soll auf einen neuen Server umziehen.

Nun ja mittlerweile habe ich die DB importiert in die neue DB :-)

Grüße Bernhard

Re: Datenbank importieren

Christian Kirsch schrieb:

> Am 20.08.2007 23:12 schrieb Claus Reibenstein:
>
>> Christian Kirsch schrieb:
>>
>>> Typisch für MySQL: Der Fehler ist immer *direkt* vor dieser Stelle.
>>
>> Ich weiß ja nicht, welches MySQL Du benutzt, aber mein MySQL meldet den
>> Fehler immer genau an der Stelle, an der er ist.
>
> Dann zitiere ich doch extra für Dich noch mal aus dem OP:
>
>> introtext mediumtext NOT NULL ,
>> FULLTEXT mediumtext NOT NULL ,
>> state tinyint( 3 ) NOT NULL default '0',
>> sectionid int( 11 ) unsigned NOT NULL default '0',

Dann zitiere ich doch extra für Dich mal aus dem Referenzhandbuch:

,----------
| CREATE [TEMPORARY] TABLE [IF NOT EXISTS] tbl_name
| [(create_definition,...)]
| [table_options] [select_statement]
`----------

,----------
| create_definition:
| column_definition
| | [CONSTRAINT [symbol]] PRIMARY KEY [index_type]
| (index_col_name,...)
| | KEY [index_name] [index_type] (index_col_name,...)
| | INDEX [index_name] [index_type] (index_col_name,...)
| | [CONSTRAINT [symbol]] UNIQUE [INDEX]
| [index_name] [index_type] (index_col_name,...)
| | FULLTEXT [INDEX] [index_name] (index_col_name,...)
| [WITH PARSER parser_name]
| | SPATIAL [INDEX] [index_name] (index_col_name,...)
| | [CONSTRAINT [symbol]] FOREIGN KEY
| [index_name] (index_col_name,...) [reference_definition]
| | CHECK (expr)
`----------

Du siehst: FULLTEXT ist an dieser Stelle syntaktisch vollkommen korrekt.
Danach soll jedoch entweder das Schlüsselwort INDEX oder ein Indexname
folgen. Es folgt jedoch das Schlüsselwort MEDIUMTEXT, und das ist
syntaktisch falsch. Und genau das hat auch MySQL gemeldet:

>> #1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the
>> right syntax to use near 'mediumtext NOT NULL,
>
> Der Fehler ist "FULLTEXT"

Nein. Der Fehler ist MEDIUMTEXT.

>> Allerdings kann MySQL nur syntaktische Fehler erkennen,
>
> Das *ist* ein syntaktischer Fehler.

Der _syntaktische_ Fehler lautet aber nicht FULLTEXT, sondern MEDIUMTEXT.

> Die Syntax von MySQLs SQL-Dialekt
> legt fest, welche Wörter reserviert und nicht ohne weiteres als
> Spaltennamen zulässig sind. Ein reserviertes Wort als Spaltenname zu
> verwenden, hat nichts mit der Semantik zu tun.

An dieser Stelle _kann_ ein Spaltenname stehen, _muss_ aber nicht. Das
Schlüsselwort FULLTEXT ist an dieser Stelle syntaktisch ok.

> Das Problem ist der Parser von MySQL, der zwar merkt, dass es einen
> Fehler gibt, aber keine Lust hat, rückwärts zu gucken, wo denn dieser
> Fehler genau herkommt.

Nach welchen Kriterien soll der Parser das entscheiden können? Der
Parser kann nur nach der Syntaxdefinition gehen, und gemäß dieser
Syntaxdefinition ist das Statement bis einschließlich FULLTEXT
syntaktisch in Ordnung.

Gruß. Claus

Re: Datenbank importieren

Christian Kirsch schrieb:

> Am 21.08.2007 11:13 schrieb Bernhard.Schimanski:
>
>> Christian Kirsch schrieb:
>
>>> Hint: Dein Server/Deine DB/Deine Tabelle benutzt UTF-8 für alle
>>> char/varchar-Spalten. Bist Du sicher, dass "permalink" und/oder "type"
>>> (wieder so ein ungeschickter Spaltenname) wirklich UTF-8-Daten brauchen?
>>
>> Ja, es ist kein Schlüsselwort.
>
> *Noch* nicht. Deshalb schrieb ich ja "ungeschickt". Auch "time" war
> früher kein Schlüsselwort, IIRC.

Wenn man sich angewöhnt, Datenbank-, Tabellen- und Spaltennamen
konsequent in Backticks (`) oder - im ANSI-MODE - Anführungszeichen (")
zu setzen, sind Schlüsselwörter kein Problem. Eine Alternative ist, für
solche Namen grundsätzlich keine englischen, sondern z.B. deutsche
Wörter zu benutzen.

> Die Frage, ob Du an dieser Stelle
> UTF-8 brauchst, hast Du nicht beantwortet.

Ich würde das "Ja" darauf beziehen :-)

Gruß. Claus

Re: Datenbank importieren

"Bernhard.Schimanski" <100.236719@germanynet.de> wrote:

> ...
> (Ein älterer Standard für die UTF-8-Kodierung ist in RFC 2279 enthalten, wo UTF-8-Sequenzen mit einer Länge von bis zu 6
> Byte beschrieben werden. RFC 3629 hat RFC 2279 ersetzt, weswegen Sequenzen mit 5 oder 6 Byte heute nicht mehr verwendet
> werden.)
> ...
> http://www.mysql.org/doc/refman/5.1/de/charset-unicode.html

Etwas genauer gesagt ist es so, daß derzeit Unicode-Zeichen nur von
U+0000 bis U+10FFFF definiert sind. Diesen Zeichenvorrat kann man mit
maximal 4 Byte utf8 Sequenzen darstellen.

MySQL ist sogar noch weiter eingeschränkt: es unterstützt nur die Basic
Multilingual Plane (U+0000 bis U+FFFF). Dafür reichen 3 Bytes utf8.

> Eine andere Erklärung, die ich im Netz gefunden habe:
> Jedes UTF-8 Zeichen ist genauer betrachtet 3 Bytes lang.

Ein Zeichen in einem utf8-String kann *maximal* 3 Bytes lang sein.
Bei der Definition eines Index geht MySQL vom worst case aus und
nimmt an ein Index auf N utf8 Zeichen verbrauche 3*N Bytes.

> Indexe in MySQL können bis zu 1000 Byte lang sein (767 Byte bei
> InnoDB-Tabellen). Beachten Sie, dass die Grenzen in Byte gemessen werden, im Gegensatz zu der Länge einer Spalte, die in
> Anzahl von Zeichen interpretiert wird.
>
> Das würde für mich heißen, dass ich beim anlegen der Tabelle, die Zeichen angaben begrenzen muss?

Du kannst keinen Index über mehr als 333 utf8 Zeichen anlegen.


XL

Re: Datenbank importieren

Christian Kirsch wrote:
> Am 21.08.2007 10:55 schrieb Daniel Fischer:
>> Christian Kirsch!
>>
>>> Der Fehler ist "FULLTEXT" - und damit genau *vor* dem, was MySQL
>>> anmeckert. Der MySQL-Parser hat diese Macke schon seit Ewigkeiten.
>>
>> Nein. Der Fehler ist "mediumtext NOT NULL". Bis inklusive FULLTEXT ist
>> das noch eine korrekte Spezifikation eines Volltextindexes. Das ist
>> jedenfalls die Auffassung von MySQL.
>
> ACK. Es bleibt also bei meiner Daumenregel: Der Fehler ist immer genau
> *vor* dem ersten Wort, das MySQL nicht gefällt. Und meine erste
> Interpretation, "FULLTEXT" sei als Spaltenname nicht erlaubt, weil
> eben Keyword, ist damit auch hinfällig.

Nein, ist sie nicht.

Die Sache ist nur die, daß da entweder eine Spaltendefinition oder eine
Indexdefinition stehen kann. Und die Definition eines Volltext-Index
würde genau mit dem Wort FULLTEXT beginnen.

> Meine Kritik
> am MySQL-Parser heißt ja, kurzgefasst, dass er eigentlich immer einen
> Syntaxfehler meldet, der *hinter* dem eigentlichen liegt.

Das ist eine Eigenart aller mit yacc (bzw. bison) generierten Parser:
sie melden einen Fehler beim ersten Symbol für das es keine Regel gibt.
Für eine Zeile in CREATE TABLE, die mit FULLTEXT beginnt, *gibt* es
aber eine Regel. Nur die Fortsetzung 'mediumtext NOT NULL ...' paßt
dann nicht mehr. Weil sie die Regel für den optionalen Indexnamen und
die Auflistung der zu indizierenden Spalten nicht matcht.


XL

Re: Datenbank importieren

Am 21.08.2007 14:46 schrieb Axel Schwenke:
> Christian Kirsch wrote:

>> Meine Kritik
>> am MySQL-Parser heißt ja, kurzgefasst, dass er eigentlich immer einen
>> Syntaxfehler meldet, der *hinter* dem eigentlichen liegt.
>
> Das ist eine Eigenart aller mit yacc (bzw. bison) generierten Parser:
> sie melden einen Fehler beim ersten Symbol für das es keine Regel gibt.

Aber es sollte doch möglich sein, Kontextinformationen mitzuführen?
Immerhin gibt es doch den Parsetree *bis* zu dieser Stelle, bzw. es
gibt eine Regel, die mit "FULLTEXT" anfängt und mit dem Rest der
Indexdefinition weiter geht.

> Für eine Zeile in CREATE TABLE, die mit FULLTEXT beginnt, *gibt* es
> aber eine Regel. Nur die Fortsetzung 'mediumtext NOT NULL ...' paßt
> dann nicht mehr. Weil sie die Regel für den optionalen Indexnamen und
> die Auflistung der zu indizierenden Spalten nicht matcht.
>

Sag' ich doch: Daraus könnte man deutlich mehr machen als "Syntax
error", sondern eben "Illegal Fulltext definition".

Konkret (mysql 5.0.22, sql_yacc.yy):

key_type:
key_or_index { $$= Key::MULTIPLE; }
| FULLTEXT_SYM opt_key_or_index { $$= Key::FULLTEXT; }
| SPATIAL_SYM opt_key_or_index

und später dann

key_or_index:
KEY_SYM {}
| INDEX_SYM {};

Da passiert m.E. *gar* keine Fehlerbehandlung über die hinaus, die
YACC ohnehin anbietet. Immerhin scheint aber in $$ schon
"Key::FULLTEXT" drin zu stehen, wenn key_or_index scheitert. Aber ich
mag mich irren - meine YACC-Zeit liegt schon lange zurück.


--
Christian

Re: Datenbank importieren

Christian Kirsch wrote:
> Am 21.08.2007 14:46 schrieb Axel Schwenke:
>> Christian Kirsch wrote:
>
>>> Meine Kritik
>>> am MySQL-Parser heißt ja, kurzgefasst, dass er eigentlich immer einen
>>> Syntaxfehler meldet, der *hinter* dem eigentlichen liegt.
>>
>> Das ist eine Eigenart aller mit yacc (bzw. bison) generierten Parser:
>> sie melden einen Fehler beim ersten Symbol für das es keine Regel gibt.
>
> Aber es sollte doch möglich sein, Kontextinformationen mitzuführen?

Intern tut der Bison-generierte Code das sicherlich. Aber AFAIK gibt es
keine einfache Möglichkeit, da ran zu kommen.

> Immerhin gibt es doch den Parsetree *bis* zu dieser Stelle, bzw. es
> gibt eine Regel, die mit "FULLTEXT" anfängt und mit dem Rest der
> Indexdefinition weiter geht.

Der generierte Parser ist ein simpler Stack-Automat. Von Regeln weiß
der nix mehr. Der kennt nur noch Nummern von Symbolen und erlaubte
Folgen von Symbolen (implementiert als Zustandsübergangstabelle).
Du kannst ja spaßeshalber mal den generierten Code lesen ;-)

> Sag' ich doch: Daraus könnte man deutlich mehr machen als "Syntax
> error", sondern eben "Illegal Fulltext definition".
>
> Da passiert m.E. *gar* keine Fehlerbehandlung über die hinaus, die
> YACC ohnehin anbietet.

Du sagst es.

> Immerhin scheint aber in $$ schon
> "Key::FULLTEXT" drin zu stehen, wenn key_or_index scheitert.

Der Parser hat bereits einen ganzen Stapel von Symbolen abgearbeitet -
genau genommen sind das *alle* Symbole seit Anfang des SQL-Statements.
Wenn es keine passende Regel mehr gibt, aber weiter vorn mehrere Regeln
möglich gewesen wären, löst der Parser den ganzen Zirkus wieder auf und
versucht andere Möglichkeiten. Wenn es nicht mehr weiter geht, gibt der
Parser nach dem längsten möglichen Match auf. Der eigentliche Fehler
*kann* aber viel weiter vorn liegen.

Als Menschen können wir sagen, daß CREATE TABLE in einigermaßen
unabhängige Definitionen von Spalten und Indexen zerfällt und daß es
recht unwahrscheinlich ist einen Syntaxfehler zu bekommen, wo die
Fehlerursache weit von der Stelle entfernt liegt, an der der Parser
aufgeben muß. Dem (generierten) Parser fehlt diese Einsicht.

Ein handgeschriebener Parser könnte das besser hinbekommen, z.B. indem
er die Kommata im CREATE TABLE als Terminierungssymbole betrachtet.
D.h. wenn er bis zum Komma eine gültige Syntax hatte, sucht er weiter
vorne nicht mehr nach alternativen Interpretationen. Bei einem Fehler
kann er dann alles nach dem letzten gelesenen Terminatorsymbol ausgeben
und sagen daß da der Fehler stecken muß.

> Aber ich mag mich irren - meine YACC-Zeit liegt schon lange zurück.

Dito. Aber was ich mir gemerkt habe ist, daß Fehlerbehandlung in
yacc/bison Parsern häßlich ist.

Aber dem Vernehmen nach sind die Tage des Bison-Parsers in MySQL
ohnehin gezählt. Aktuelle CPUs mögen die doch recht großen Sprung-
tabellen nicht besonders bzw. die verfügbaren Compiler schaffen es
nicht, daraus Maschinencode mit genügend großer Cache-Lokalität zu
zaubern.


XL