Hello,

i've a running 4.0 Mysql DB (A) and want to upgrade to 5.0 on Etch (B).
Because of upgrading the hardware also (new Server), i rynced the
mysqldatadir from A to B.

B is coming up properly, i run all the scripts recommend by the manual,
but i have three tables, that have now status "already up to date" but
if i check this tables i got the message "use Repair". I did this, but
with no success (still "already up to date")

The strange thing is, that the most tables have the same structure, only
three from about 50 have this problem.

Is this a known problem?

Thanks
Daniel

== Quote from Daniel Maus (daniel.maus@psychologie.uni-mannheim.de)'s article
> Hello,
> i've a running 4.0 Mysql DB (A) and want to upgrade to 5.0 on Etch (B).
> Because of upgrading the hardware also (new Server), i rynced the
> mysqldatadir from A to B.
> B is coming up properly, i run all the scripts recommend by the manual,
> but i have three tables, that have now status "already up to date" but
> if i check this tables i got the message "use Repair". I did this, but
> with no success (still "already up to date")
> The strange thing is, that the most tables have the same structure, only
> three from about 50 have this problem.
> Is this a known problem?
> Thanks
> Daniel

that is not a known problem. if your tables are myisam, better run myisamchk
(check all the switches/parameteres it takes). and then see what happens. another
step would be to dump the tables into a text file and drop the tables and recreate
from scratch and then load the data. but mostly myisamchk should work.
--
POST BY: lark with PHP News Reader

>> i've a running 4.0 Mysql DB (A) and want to upgrade to 5.0 on Etch (B).
>> Because of upgrading the hardware also (new Server), i rynced the
>> mysqldatadir from A to B.
>> B is coming up properly, i run all the scripts recommend by the manual,
>> but i have three tables, that have now status "already up to date" but
>> if i check this tables i got the message "use Repair". I did this, but
>> with no success (still "already up to date")
>> The strange thing is, that the most tables have the same structure, only
>> three from about 50 have this problem.
>> Is this a known problem?
>
> that is not a known problem. if your tables are myisam, better run myisamchk
> (check all the switches/parameteres it takes). and then see what happens. another
> step would be to dump the tables into a text file and drop the tables and recreate
> from scratch and then load the data. but mostly myisamchk should work.


Hi,
i checked the tables already with myisamchk also with the same result.
Even with -e (and others i tried) i got no message about repairing any
problems. The errormessages that i got seems to say, that the tables
need to be upgraded. Is it possible to see, which version a table have?

I hope i can avoid dumping - deleten and reimporting the tables because
the B is set up as a slave for A, so i can do some select test to look
if there are any side effects with my applications and have already an
up to date dataset on B to switch it any time quickly productive (and
shut down A)

Any hints?

Thanks
Daniel

== Quote from Daniel Maus (maus@rumms.uni-mannheim.de)'s article
> >> i've a running 4.0 Mysql DB (A) and want to upgrade to 5.0 on Etch (B).
> >> Because of upgrading the hardware also (new Server), i rynced the
> >> mysqldatadir from A to B.
> >> B is coming up properly, i run all the scripts recommend by the manual,
> >> but i have three tables, that have now status "already up to date" but
> >> if i check this tables i got the message "use Repair". I did this, but
> >> with no success (still "already up to date")
> >> The strange thing is, that the most tables have the same structure, only
> >> three from about 50 have this problem.
> >> Is this a known problem?
> >
> > that is not a known problem. if your tables are myisam, better run myisamchk
> > (check all the switches/parameteres it takes). and then see what happens. another
> > step would be to dump the tables into a text file and drop the tables and recreate
> > from scratch and then load the data. but mostly myisamchk should work.
> Hi,
> i checked the tables already with myisamchk also with the same result.
> Even with -e (and others i tried) i got no message about repairing any
> problems. The errormessages that i got seems to say, that the tables
> need to be upgraded. Is it possible to see, which version a table have?
> I hope i can avoid dumping - deleten and reimporting the tables because
> the B is set up as a slave for A, so i can do some select test to look
> if there are any side effects with my applications and have already an
> up to date dataset on B to switch it any time quickly productive (and
> shut down A)
> Any hints?
> Thanks
> Daniel


what happens when you run a "select" on one of these tables?

can you post the error messages you get?
--
POST BY: lark with PHP News Reader

> what happens when you run a "select" on one of these tables?
>
> can you post the error messages you get?

Select runs fine. Here the errormessages, that i got from
mysqlcheck --check-upgrade --all-databases --auto-repair

[...]
foobar.variablen_eingabe
error : Table upgrade required. Please do "REPAIR TABLE
`variablen_eingabe`" to fix it!
[...]

Repairing tables
foobar.variablen_eingabe Table is already up to date


Then i repair the table:

mysql> repair table variablen_eingabe;
+----------------------------------------------+--------+----------+-----------------------------+
| Table | Op | Msg_type |
Msg_text |
+----------------------------------------------+--------+----------+-----------------------------+
| Allianz_Weiterbildung_2005.variablen_eingabe | repair | status |
Table is already up to date |
+----------------------------------------------+--------+----------+-----------------------------+
1 row in set, 1 warning (0.01 sec)

After that i check the tables again with
mysqlcheck --check-upgrade --all-databases --auto-repair
and get the same result as in the first run


[...]
foobar.variablen_eingabe
error : Table upgrade required. Please do "REPAIR TABLE
`variablen_eingabe`" to fix it!
[...]

Repairing tables
foobar.variablen_eingabe Table is already up to date

Thanks for any hint
Daniel

== Quote from Daniel Maus (daniel.maus@psychologie.uni-mannheim.de)'s article
> > what happens when you run a "select" on one of these tables?
> >
> > can you post the error messages you get?
> Select runs fine. Here the errormessages, that i got from
> mysqlcheck --check-upgrade --all-databases --auto-repair
> [...]
> foobar.variablen_eingabe
> error : Table upgrade required. Please do "REPAIR TABLE
> `variablen_eingabe`" to fix it!
> [...]
> Repairing tables
> foobar.variablen_eingabe Table is already up to date
> Then i repair the table:
> mysql> repair table variablen_eingabe;
>
+----------------------------------------------+--------+----------+-----------------------------+
> | Table | Op | Msg_type |
> Msg_text |
>
+----------------------------------------------+--------+----------+-----------------------------+
> | Allianz_Weiterbildung_2005.variablen_eingabe | repair | status |
> Table is already up to date |
>
+----------------------------------------------+--------+----------+-----------------------------+
> 1 row in set, 1 warning (0.01 sec)
> After that i check the tables again with
> mysqlcheck --check-upgrade --all-databases --auto-repair
> and get the same result as in the first run
> [...]
> foobar.variablen_eingabe
> error : Table upgrade required. Please do "REPAIR TABLE
> `variablen_eingabe`" to fix it!
> [...]
> Repairing tables
> foobar.variablen_eingabe Table is already up to date
> Thanks for any hint
> Daniel


i think you may want to bring the db server off line and run the myisamchk utility
on your data files and their related index files. basically you'll run this:

before doing anything, take a dump of the tables that need repairing. you can do
this with mysqldump.

then, bring the database offline; because myisamchk cannot access the files while
the server is accessing the table's data files.

before we get to the extended stuff, you should run the myisamchk utility on your
tables:

myisamchk Table
remember to run the myisamchk on index files as well:
myisamchk Table.MYI

then to repair them run something like this:
myisamchk --recover Table

if the repair op with the --recover cannot fix the problems it finds, try using
the --safe-recover option. this one can fix some more problems but a bit slower.

let us know how it goes.
--
POST BY: lark with PHP News Reader

> i think you may want to bring the db server off line and run the myisamchk utility
> on your data files and their related index files. basically you'll run this:
>
> before doing anything, take a dump of the tables that need repairing. you can do
> this with mysqldump.
>
> then, bring the database offline; because myisamchk cannot access the files while
> the server is accessing the table's data files.
>
> before we get to the extended stuff, you should run the myisamchk utility on your
> tables:
>
> myisamchk Table
> remember to run the myisamchk on index files as well:
> myisamchk Table.MYI
>
> then to repair them run something like this:
> myisamchk --recover Table
>
> if the repair op with the --recover cannot fix the problems it finds, try using
> the --safe-recover option. this one can fix some more problems but a bit slower.
>
> let us know how it goes.
> --
Hi,

i run myisamchk with -e before, with no effects. Now i follow your
approach, but with no success. it repairs something, but i still get
from mysqlcheck --check-upgrade the message "Table upgrade required.
Please do a repair table ..."

I see no way to fix this. D oyou have any ideas any more?

_Many_ thanks
Daniel

== Quote from Daniel Maus (maus@rumms.uni-mannheim.de)'s article
> > i think you may want to bring the db server off line and run the myisamchk utility
> > on your data files and their related index files. basically you'll run this:
> >
> > before doing anything, take a dump of the tables that need repairing. you can do
> > this with mysqldump.
> >
> > then, bring the database offline; because myisamchk cannot access the files while
> > the server is accessing the table's data files.
> >
> > before we get to the extended stuff, you should run the myisamchk utility on your
> > tables:
> >
> > myisamchk Table
> > remember to run the myisamchk on index files as well:
> > myisamchk Table.MYI
> >
> > then to repair them run something like this:
> > myisamchk --recover Table
> >
> > if the repair op with the --recover cannot fix the problems it finds, try using
> > the --safe-recover option. this one can fix some more problems but a bit slower.
> >
> > let us know how it goes.
> > --
> Hi,
> i run myisamchk with -e before, with no effects. Now i follow your
> approach, but with no success. it repairs something, but i still get
> from mysqlcheck --check-upgrade the message "Table upgrade required.
> Please do a repair table ..."
> I see no way to fix this. D oyou have any ideas any more?
> _Many_ thanks
> Daniel


i don't know if you've run this:
mysqlcheck --repair --extended tablename

post the results, would you?
--
POST BY: lark with PHP News Reader

>>> if the repair op with the --recover cannot fix the problems it finds, try using
>>> the --safe-recover option. this one can fix some more problems but a bit slower.
>>>
>>> let us know how it goes.
>>> --
>> Hi,
>> i run myisamchk with -e before, with no effects. Now i follow your
>> approach, but with no success. it repairs something, but i still get
>> from mysqlcheck --check-upgrade the message "Table upgrade required.
>> Please do a repair table ..."
>> I see no way to fix this. D oyou have any ideas any more?
>> _Many_ thanks
>> Daniel
>
>
> i don't know if you've run this:
> mysqlcheck --repair --extended tablename
>
> post the results, would you?
> --


-e and --extended are the same, and i tried with -e already, but i give
you a chance ;-)

Same results, but i tested something other and maybe this is the
problem. I tried to copy this 'faulty' table to see, if its possible.
"And here are the results" ;-)

4.0.15 -> no Problem
5.0.32-Debian_7etch1
-> Problem "#1166 - Incorrect column name '002_Info_58o '"
(with space at the end, seen in myphpadmin)

Is 'info' in mysql 5 a reserved word, but not in V4 or where is the problem?

Thanks
Daniel


The query was:
CREATE TABLE `foobar`.`variablen_eingabe_bak` (
`code` varchar( 50 ) NOT NULL default '',
`fragebogen_aktuell` int( 11 ) NOT NULL default '0',
`befragung` tinyint( 3 ) NOT NULL default '0',
`datum_aktueller_bogen` timestamp NOT NULL default CURRENT_TIMESTAMP ON
UPDATE CURRENT_TIMESTAMP ,
`datum_beginn` timestamp NOT NULL default '0000-00-00 00:00:00',
`datum_ende` timestamp NOT NULL default '0000-00-00 00:00:00',
`browser` varchar( 100 ) default NULL ,
`fbPrintedYet` enum( 'many', 'yes', 'no' ) NOT NULL default 'no',
`002_Info_58o ` text NOT NULL ,
`002_WKA_66` text NOT NULL ,
`002_WKA_67a` text NOT NULL ,
`002_WKA_67b` text NOT NULL ,
`002_WKA_67c` text NOT NULL ,
`002_WKA_67d` text NOT NULL ,
`002_WKA_67e` text NOT NULL ,
`002_WKA_67o` text NOT NULL ,
`002_WKA_68o ` text NOT NULL ,
`002_WKA_68a` text NOT NULL ,
`002_WKA_68b` text NOT NULL ,
`002_WKA_68c` text NOT NULL ,
`002_WKA_68d` text NOT NULL ,
`002_WKA_68e` text NOT NULL ,
`002_WKA_68f` text NOT NULL ,
`002_WKA_68g` text NOT NULL ,
`002_WKA_68o` text NOT NULL ,
`002_EWB_1` text NOT NULL ,
`002_EWB_2` text NOT NULL ,
`002_EWB_3` text NOT NULL ,
`002_EWB4_a1` text NOT NULL ,
`002_EWB4_a2` text NOT NULL ,
`002_EWB4_a3` text NOT NULL ,
`002_EWB4_a4` text NOT NULL ,
`002_EWB4_a5` text NOT NULL ,
`002_EWB4_ao` text NOT NULL ,
`002_EWB4_b1` text NOT NULL ,
`002_EWB4_b2` text NOT NULL ,
`002_EWB4_b3` text NOT NULL ,
`002_EWB4_b4` text NOT NULL ,
`002_EWB4_b5` text NOT NULL ,
`002_EWB4_bo` text NOT NULL ,
`002_EWB_5` text NOT NULL ,
`002_BWB_8` text NOT NULL ,
`002_BWB_9` text NOT NULL ,
`002_BWB_10` text NOT NULL ,
`002_BWB_11` text NOT NULL ,
`002_BWB12_a` text NOT NULL ,
`002_BWB12_b` text NOT NULL ,
`002_BWB12_c` text NOT NULL ,
`002_BWB12_d` text NOT NULL ,
`002_BWB_12o` text NOT NULL ,
`002_BWB13_a` text NOT NULL ,
`002_BWB13_b` text NOT NULL ,
`002_BWB13_c` text NOT NULL ,
`002_BWB13_d` text NOT NULL ,
`002_BWB13_e` text NOT NULL ,
`002_BWB13o` text NOT NULL ,
`002_BWB_14` text NOT NULL ,
`002_BWB_15` text NOT NULL ,
`002_BWB_16` text NOT NULL ,
`002_BWB_17` text NOT NULL ,
`002_BWB_18` text NOT NULL ,
`002_BWB_19` text NOT NULL ,
`002_BWB_20` text NOT NULL ,
`002_BWB_21` text NOT NULL ,
`002_BWB_22` text NOT NULL ,
`002_BWB_23` text NOT NULL ,
`002_BWB_24` text NOT NULL ,
`002_BWB_25` text NOT NULL ,
`002_BWB_26` text NOT NULL ,
`002_BWB_27` text NOT NULL ,
`002_BWB_28` text NOT NULL ,
`002_BWB_29` text NOT NULL ,
`002_BWB_30` text NOT NULL ,
`002_BWB_31` text NOT NULL ,
`002_BWB_32` text NOT NULL ,
`002_BWB_33_a` text NOT NULL ,
`002_BWB_33_b` text NOT NULL ,
`002_BWB_33_c` text NOT NULL ,
`002_BWB_33_d` text NOT NULL ,
`002_BWB_33_e` text NOT NULL ,
`002_BWB_33o` text NOT NULL ,
`002_BWB_33_g` text NOT NULL ,
`002_ETW_34` text NOT NULL ,
`002_ETW_35` text NOT NULL ,
`002_ETW_36` text NOT NULL ,
`002_ETW_37` text NOT NULL ,
`002_ETW_38` text NOT NULL ,
`002_ETW_39` text NOT NULL ,
`002_ETW_40` text NOT NULL ,
`002_ETW_41` text NOT NULL ,
`002_ETW_42` text NOT NULL ,
`002_ETW_43` text NOT NULL ,
`002_ETW_44` text NOT NULL ,
`002_ETW_45` text NOT NULL ,
`002_ETW_46` text NOT NULL ,
`002_ETW_47` text NOT NULL ,
`002_ETW_48` text NOT NULL ,
`002_ETW_49` text NOT NULL ,
`002_ETW_50` text NOT NULL ,
`002_ETW_51` text NOT NULL ,
`002_ETW_52` text NOT NULL ,
`002_Info_53` text NOT NULL ,
`002_Info_54` text NOT NULL ,
`002_Info_55` text NOT NULL ,
`002_Info_56` text NOT NULL ,
`002_Info_57` text NOT NULL ,
`002_Info_58a` text NOT NULL ,
`002_Info_58b` text NOT NULL ,
`002_Info_58c` text NOT NULL ,
`002_Info_58d` text NOT NULL ,
`002_Info_58e` text NOT NULL ,
`002_Info_58f` text NOT NULL ,
`002_Info_58o` text NOT NULL ,
`002_EWB6_a` text NOT NULL ,
`002_EWB6_b` text NOT NULL ,
`002_EWB6_c` text NOT NULL ,
`002_EWB6_d` text NOT NULL ,
`002_EWB6_e` text NOT NULL ,
`002_EWB6_f` text NOT NULL ,
`002_EWB6_g` text NOT NULL ,
`002_EWB6_h` text NOT NULL ,
`002_EWB_7` text NOT NULL ,
`002_EWB_7o` text NOT NULL ,
`002_Info_59` text NOT NULL ,
`002_Info_60` text NOT NULL ,
`002_Info_61` text NOT NULL ,
`002_Info_62` text NOT NULL ,
`002_Info_63` text NOT NULL ,
`002_Info_64` text NOT NULL ,
`002_Info_65` text NOT NULL ,
`002_Info_66` text NOT NULL ,
`002_Info_65o` text NOT NULL ,
`002_P_69` text NOT NULL ,
`002_P_70` text NOT NULL ,
`002_P_71` text NOT NULL ,
`002_P_72` text NOT NULL ,
`002_P_73` text NOT NULL ,
`002_P_74` text NOT NULL ,
`002_P_75` text NOT NULL ,
`002_P_76` text NOT NULL ,
`002_P_77` text NOT NULL ,
`002_P_78` text NOT NULL ,
PRIMARY KEY ( `code` ) ,
KEY `fragebogen_aktuell` ( `fragebogen_aktuell` )
) ENGINE = MYISAM DEFAULT CHARSET = latin1 COMMENT = 'Usereingaben'

== Quote from Daniel Maus (maus@rumms.uni-mannheim.de)'s article
> >>> if the repair op with the --recover cannot fix the problems it finds, try using
> >>> the --safe-recover option. this one can fix some more problems but a bit slower.
> >>>
> >>> let us know how it goes.
> >>> --
> >> Hi,
> >> i run myisamchk with -e before, with no effects. Now i follow your
> >> approach, but with no success. it repairs something, but i still get
> >> from mysqlcheck --check-upgrade the message "Table upgrade required.
> >> Please do a repair table ..."
> >> I see no way to fix this. D oyou have any ideas any more?
> >> _Many_ thanks
> >> Daniel
> >
> >
> > i don't know if you've run this:
> > mysqlcheck --repair --extended tablename
> >
> > post the results, would you?
> > --
> -e and --extended are the same, and i tried with -e already, but i give
> you a chance ;-)
> Same results, but i tested something other and maybe this is the
> problem. I tried to copy this 'faulty' table to see, if its possible.
> "And here are the results" ;-)
> 4.0.15 -> no Problem
> 5.0.32-Debian_7etch1
> -> Problem "#1166 - Incorrect column name '002_Info_58o '"
> (with space at the end, seen in myphpadmin)
> Is 'info' in mysql 5 a reserved word, but not in V4 or where is the problem?
> Thanks
> Daniel
> The query was:
> CREATE TABLE `foobar`.`variablen_eingabe_bak` (
> `code` varchar( 50 ) NOT NULL default '',
> `fragebogen_aktuell` int( 11 ) NOT NULL default '0',
> `befragung` tinyint( 3 ) NOT NULL default '0',
> `datum_aktueller_bogen` timestamp NOT NULL default CURRENT_TIMESTAMP ON
> UPDATE CURRENT_TIMESTAMP ,
> `datum_beginn` timestamp NOT NULL default '0000-00-00 00:00:00',
> `datum_ende` timestamp NOT NULL default '0000-00-00 00:00:00',
> `browser` varchar( 100 ) default NULL ,
> `fbPrintedYet` enum( 'many', 'yes', 'no' ) NOT NULL default 'no',
> `002_Info_58o ` text NOT NULL ,
> `002_WKA_66` text NOT NULL ,
> `002_WKA_67a` text NOT NULL ,
> `002_WKA_67b` text NOT NULL ,
> `002_WKA_67c` text NOT NULL ,
> `002_WKA_67d` text NOT NULL ,
> `002_WKA_67e` text NOT NULL ,
> `002_WKA_67o` text NOT NULL ,
> `002_WKA_68o ` text NOT NULL ,
> `002_WKA_68a` text NOT NULL ,
> `002_WKA_68b` text NOT NULL ,
> `002_WKA_68c` text NOT NULL ,
> `002_WKA_68d` text NOT NULL ,
> `002_WKA_68e` text NOT NULL ,
> `002_WKA_68f` text NOT NULL ,
> `002_WKA_68g` text NOT NULL ,
> `002_WKA_68o` text NOT NULL ,
> `002_EWB_1` text NOT NULL ,
> `002_EWB_2` text NOT NULL ,
> `002_EWB_3` text NOT NULL ,
> `002_EWB4_a1` text NOT NULL ,
> `002_EWB4_a2` text NOT NULL ,
> `002_EWB4_a3` text NOT NULL ,
> `002_EWB4_a4` text NOT NULL ,
> `002_EWB4_a5` text NOT NULL ,
> `002_EWB4_ao` text NOT NULL ,
> `002_EWB4_b1` text NOT NULL ,
> `002_EWB4_b2` text NOT NULL ,
> `002_EWB4_b3` text NOT NULL ,
> `002_EWB4_b4` text NOT NULL ,
> `002_EWB4_b5` text NOT NULL ,
> `002_EWB4_bo` text NOT NULL ,
> `002_EWB_5` text NOT NULL ,
> `002_BWB_8` text NOT NULL ,
> `002_BWB_9` text NOT NULL ,
> `002_BWB_10` text NOT NULL ,
> `002_BWB_11` text NOT NULL ,
> `002_BWB12_a` text NOT NULL ,
> `002_BWB12_b` text NOT NULL ,
> `002_BWB12_c` text NOT NULL ,
> `002_BWB12_d` text NOT NULL ,
> `002_BWB_12o` text NOT NULL ,
> `002_BWB13_a` text NOT NULL ,
> `002_BWB13_b` text NOT NULL ,
> `002_BWB13_c` text NOT NULL ,
> `002_BWB13_d` text NOT NULL ,
> `002_BWB13_e` text NOT NULL ,
> `002_BWB13o` text NOT NULL ,
> `002_BWB_14` text NOT NULL ,
> `002_BWB_15` text NOT NULL ,
> `002_BWB_16` text NOT NULL ,
> `002_BWB_17` text NOT NULL ,
> `002_BWB_18` text NOT NULL ,
> `002_BWB_19` text NOT NULL ,
> `002_BWB_20` text NOT NULL ,
> `002_BWB_21` text NOT NULL ,
> `002_BWB_22` text NOT NULL ,
> `002_BWB_23` text NOT NULL ,
> `002_BWB_24` text NOT NULL ,
> `002_BWB_25` text NOT NULL ,
> `002_BWB_26` text NOT NULL ,
> `002_BWB_27` text NOT NULL ,
> `002_BWB_28` text NOT NULL ,
> `002_BWB_29` text NOT NULL ,
> `002_BWB_30` text NOT NULL ,
> `002_BWB_31` text NOT NULL ,
> `002_BWB_32` text NOT NULL ,
> `002_BWB_33_a` text NOT NULL ,
> `002_BWB_33_b` text NOT NULL ,
> `002_BWB_33_c` text NOT NULL ,
> `002_BWB_33_d` text NOT NULL ,
> `002_BWB_33_e` text NOT NULL ,
> `002_BWB_33o` text NOT NULL ,
> `002_BWB_33_g` text NOT NULL ,
> `002_ETW_34` text NOT NULL ,
> `002_ETW_35` text NOT NULL ,
> `002_ETW_36` text NOT NULL ,
> `002_ETW_37` text NOT NULL ,
> `002_ETW_38` text NOT NULL ,
> `002_ETW_39` text NOT NULL ,
> `002_ETW_40` text NOT NULL ,
> `002_ETW_41` text NOT NULL ,
> `002_ETW_42` text NOT NULL ,
> `002_ETW_43` text NOT NULL ,
> `002_ETW_44` text NOT NULL ,
> `002_ETW_45` text NOT NULL ,
> `002_ETW_46` text NOT NULL ,
> `002_ETW_47` text NOT NULL ,
> `002_ETW_48` text NOT NULL ,
> `002_ETW_49` text NOT NULL ,
> `002_ETW_50` text NOT NULL ,
> `002_ETW_51` text NOT NULL ,
> `002_ETW_52` text NOT NULL ,
> `002_Info_53` text NOT NULL ,
> `002_Info_54` text NOT NULL ,
> `002_Info_55` text NOT NULL ,
> `002_Info_56` text NOT NULL ,
> `002_Info_57` text NOT NULL ,
> `002_Info_58a` text NOT NULL ,
> `002_Info_58b` text NOT NULL ,
> `002_Info_58c` text NOT NULL ,
> `002_Info_58d` text NOT NULL ,
> `002_Info_58e` text NOT NULL ,
> `002_Info_58f` text NOT NULL ,
> `002_Info_58o` text NOT NULL ,
> `002_EWB6_a` text NOT NULL ,
> `002_EWB6_b` text NOT NULL ,
> `002_EWB6_c` text NOT NULL ,
> `002_EWB6_d` text NOT NULL ,
> `002_EWB6_e` text NOT NULL ,
> `002_EWB6_f` text NOT NULL ,
> `002_EWB6_g` text NOT NULL ,
> `002_EWB6_h` text NOT NULL ,
> `002_EWB_7` text NOT NULL ,
> `002_EWB_7o` text NOT NULL ,
> `002_Info_59` text NOT NULL ,
> `002_Info_60` text NOT NULL ,
> `002_Info_61` text NOT NULL ,
> `002_Info_62` text NOT NULL ,
> `002_Info_63` text NOT NULL ,
> `002_Info_64` text NOT NULL ,
> `002_Info_65` text NOT NULL ,
> `002_Info_66` text NOT NULL ,
> `002_Info_65o` text NOT NULL ,
> `002_P_69` text NOT NULL ,
> `002_P_70` text NOT NULL ,
> `002_P_71` text NOT NULL ,
> `002_P_72` text NOT NULL ,
> `002_P_73` text NOT NULL ,
> `002_P_74` text NOT NULL ,
> `002_P_75` text NOT NULL ,
> `002_P_76` text NOT NULL ,
> `002_P_77` text NOT NULL ,
> `002_P_78` text NOT NULL ,
> PRIMARY KEY ( `code` ) ,
> KEY `fragebogen_aktuell` ( `fragebogen_aktuell` )
> ) ENGINE = MYISAM DEFAULT CHARSET = latin1 COMMENT = 'Usereingaben'


for sure that space in the column name is an error in version 5. that's the
problem with this create table statement.
--
POST BY: lark with PHP News Reader