Professional Web Applications Themes

Problem with upgrade 4.0 to 5.0 - MySQL

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 ...

  1. #1

    Default Problem with upgrade 4.0 to 5.0

    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
    Daniel Guest

  2. #2

    Default Re: Problem with upgrade 4.0 to 5.0

    == Quote from Daniel Maus (uni-mannheim.de)'s article 

    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
    lark Guest

  3. #3

    Default Re: Problem with upgrade 4.0 to 5.0

    >> i've a running 4.0 Mysql DB (A) and want to upgrade to 5.0 on Etch (B). 
    >
    > 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.[/ref]


    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
    Daniel Guest

  4. #4

    Default Re: Problem with upgrade 4.0 to 5.0

    == Quote from Daniel Maus (uni-mannheim.de)'s article 
    > >
    > > 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.[/ref]
    > 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[/ref]


    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
    lark Guest

  5. #5

    Default Re: Problem with upgrade 4.0 to 5.0

     

    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
    Daniel Guest

  6. #6

    Default Re: Problem with upgrade 4.0 to 5.0

    == Quote from Daniel Maus (uni-mannheim.de)'s article 
    > 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;
    >[/ref]
    +----------------------------------------------+--------+----------+-----------------------------+ 
    +----------------------------------------------+--------+----------+-----------------------------+ 
    +----------------------------------------------+--------+----------+-----------------------------+ 


    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
    lark Guest

  7. #7

    Default Re: Problem with upgrade 4.0 to 5.0

    > i think you may want to bring the db server off line and run the myisamchk utility 
    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

    Daniel Guest

  8. #8

    Default Re: Problem with upgrade 4.0 to 5.0

    == Quote from Daniel Maus (uni-mannheim.de)'s article 
    > 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[/ref]


    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
    lark Guest

  9. #9

    Default Re: Problem with upgrade 4.0 to 5.0

    >>> if the repair op with the --recover cannot fix the problems it finds, try using 
    >> 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[/ref]
    >
    >
    > i don't know if you've run this:
    > mysqlcheck --repair --extended tablename
    >
    > post the results, would you?
    > --[/ref]


    -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 CHT = latin1 COMMENT = 'Usereingaben'
    Daniel Guest

  10. #10

    Default Re: Problem with upgrade 4.0 to 5.0

    == Quote from Daniel Maus (uni-mannheim.de)'s article 
    > >
    > >
    > > i don't know if you've run this:
    > > mysqlcheck --repair --extended tablename
    > >
    > > post the results, would you?
    > > --[/ref]
    > -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 CHT = latin1 COMMENT = 'Usereingaben'[/ref]


    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
    lark Guest

  11. #11

    Default Re: Problem with upgrade 4.0 to 5.0 -> Solution

    > for sure that space in the column name is an error in version 5. that's the 

    Yes, this was the point. i modified the bad names with V4 without
    problems and reimported the tables in V5, now the tablecheck and -repair
    runs fine.

    Strange, that the tablecheck doesn't show, what the problem was. It
    seems that the tablecheck silently (i found nothing in the log) skipped
    the bad tables.

    Many thanks!
    Daniel
    Daniel Guest

  12. #12

    Default Re: Problem with upgrade 4.0 to 5.0 -> Solution

    == Quote from Daniel Maus (uni-mannheim.de)'s article 
    > Yes, this was the point. i modified the bad names with V4 without
    > problems and reimported the tables in V5, now the tablecheck and -repair
    > runs fine.
    > Strange, that the tablecheck doesn't show, what the problem was. It
    > seems that the tablecheck silently (i found nothing in the log) skipped
    > the bad tables.
    > Many thanks!
    > Daniel[/ref]

    i think this could easily be doented as a bug at mysql's website.

    --
    POST BY: lark with PHP News Reader
    lark Guest

Similar Threads

  1. Problem with CF 7 Upgrade
    By ChuckBoulineau in forum Coldfusion Server Administration
    Replies: 4
    Last Post: May 17th, 02:23 PM
  2. Upgrade from 4 to 6 problem
    By Joe_Atzinger@adobeforums.com in forum Adobe Acrobat Windows
    Replies: 2
    Last Post: April 21st, 06:29 PM
  3. UPGRADE PROBLEM 10.3
    By Brian_A_Wright@adobeforums.com in forum Adobe Illustrator Macintosh
    Replies: 3
    Last Post: April 12th, 11:13 PM
  4. Upgrade 1 to1.1 Problem need help
    By noone in forum ASP.NET General
    Replies: 1
    Last Post: July 30th, 04:05 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139