Bug #29986 Table OK on MySQL 5 not read correctly by MySQL6
Submitted: 23 Jul 2007 20:05 Modified: 25 Jul 2007 19:15
Reporter: werner landgraf Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server: Archive storage engine Severity:S2 (Serious)
Version:6.0.0 alpha OS:Linux (Kernel 2.6.23-rc1)
Assigned to: CPU Architecture:Any
Tags: storage engine, table

[23 Jul 2007 20:05] werner landgraf
Description:
A table what is correct on MySQL 5, dont work longer on MySQL 6 - error message.

The table I passed already my  #myisamchk --force --upate-state <name>  and #myisamchk -r <name>   and it dont give error message.   But with mysql > CHECK TABLE <name>   and ... REPAIR ... it gives an error message, and my forum phpBB2 dont can open that table. Also with #mysqlcheck -Ar , all tables are updated, less that one.

I want to add a copy of that table that you can examine it.

How to repeat:
In the same manner as explained above:  Try it to check with myisamchk , and try it to read with mysql.    The table, alias, is supposed to be OK, it seems to be an error of MySQL 6

Suggested fix:
I want to add a copy of that table
[23 Jul 2007 20:07] werner landgraf
table what MySQL 6 have problems to treat .MYI

Attachment: mnet_attachments_desc.MYI (application/octet-stream, text), 5.00 KiB.

[23 Jul 2007 20:08] werner landgraf
table ... .MYD

Attachment: mnet_attachments_desc.MYD (application/octet-stream, text), 3.70 KiB.

[23 Jul 2007 20:08] werner landgraf
table ... frm

Attachment: mnet_attachments_desc.frm (application/octet-stream, text), 8.74 KiB.

[24 Jul 2007 12:55] MySQL Verification Team
Thank you for the bug report. Looks like duplicate of bug:
http://bugs.mysql.com/bug.php?id=29980

Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 6.0.1-alpha-debug Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> desc `desc`;
ERROR 1034 (HY000): Incorrect key file for table 'desc'; try to repair it
mysql> check table  `desc`;
+-----------+-------+----------+-------------------------------------------------------+
| Table     | Op    | Msg_type | Msg_text                                              |
+-----------+-------+----------+-------------------------------------------------------+
| test.desc | check | error    | Incorrect key file for table 'desc'; try to repair it | 
+-----------+-------+----------+-------------------------------------------------------+
1 row in set (0.00 sec)

mysql> repair  table  `desc` USE_FRM;
+-----------+--------+----------+----------+
| Table     | Op     | Msg_type | Msg_text |
+-----------+--------+----------+----------+
| test.desc | repair | status   | OK       | 
+-----------+--------+----------+----------+
1 row in set (0.14 sec)

mysql> select count(*) from  `desc`;
+----------+
| count(*) |
+----------+
|        0 | 
+----------+
1 row in set (0.01 sec)

mysql> desc `desc`\G
*************************** 1. row ***************************
  Field: attach_id
   Type: mediumint(8) unsigned
   Null: NO
    Key: PRI
Default: NULL
  Extra: auto_increment
*************************** 2. row ***************************
  Field: physical_filename
   Type: varchar(255)
   Null: NO
    Key: MUL
Default: 
  Extra: 
*************************** 3. row ***************************
  Field: real_filename
   Type: varchar(255)
   Null: NO
    Key: 
Default: 
  Extra: 
*************************** 4. row ***************************
  Field: download_count
   Type: mediumint(8) unsigned
   Null: NO
    Key: 
Default: 0
  Extra: 
*************************** 5. row ***************************
  Field: comment
   Type: varchar(255)
   Null: YES
    Key: 
Default: NULL
  Extra: 
*************************** 6. row ***************************
  Field: extension
   Type: varchar(100)
   Null: YES
    Key: 
Default: NULL
  Extra: 
*************************** 7. row ***************************
  Field: mimetype
   Type: varchar(100)
   Null: YES
    Key: 
Default: NULL
  Extra: 
*************************** 8. row ***************************
  Field: filesize
   Type: int(20)
   Null: NO
    Key: MUL
Default: 0
  Extra: 
*************************** 9. row ***************************
  Field: filetime
   Type: int(11)
   Null: NO
    Key: MUL
Default: 0
  Extra: 
*************************** 10. row ***************************
  Field: thumbnail
   Type: tinyint(1)
   Null: NO
    Key: 
Default: 0
  Extra: 
10 rows in set (0.03 sec)

mysql>
[24 Jul 2007 15:48] werner landgraf
The instruction  REPAIR TABLE <table> USE_FRM   simply DELETED the table !!

This you call repair  ??

On the spoiled table, even the editor of the #mc showed me the contens of the table.  It is just MySQL manage it to repair what's wrong on the structure what the program itself needs ...

Have you nothing better to do this ????????????   This is not any security at all of the datas stocked with MySQL.  So its no surprise why people change to other sistems ...
[24 Jul 2007 16:05] MySQL Verification Team
What I showed you it has the same behavior of bug:
http://bugs.mysql.com/bug.php?id=29980 that is the reason
why I handled this bug as duplicate, please see the status
field and see the URL for the bug mentioned.
[25 Jul 2007 19:15] werner landgraf
I see that it is a problem of the compatibility among the versions of MySQL. I installed back v. 5.2 and there the table have no problem.  After running one time more a lot of correction / updating commands, again I installed v. 6 , and again the table dont work.  myisamchk dont reclaim about that table, only mysql v. 6 .

A serious data base sistem have to have at least the followong characteristics:
   a) compatibility for the use of the dates, among the versions 
   b) easy possibility to repair tables, inclusive manually (grafical editor)