Note: The Debian bug-reporting system has been dropped my message because "too many invalid commands found" in it. I'm resending my message and _not_ Cc:-ing it to [EMAIL PROTECTED] now. Sorry if you got it twice.
Hi! > tag 364703 moreinfo > Hi. Could you send me the example for database to reproduce the bug, > please? Thank you in advance. > > When dumping tables from MySQL 4.0 databases phpmyadmin does in include > > the auto_increment modifier for auto increment foreign keys. I've misspelled my original report such a way that affected it's meaning. The above sentence would be: When dumping tables from MySQL 4.0 databases phpmyadmin does NOT include the auto_increment modifier for auto increment foreign keys. None of our machines runs mysql 4.0 today, so I can't reproduce the above anymore. But I can give you an example that induced the bug before: Create a table with the following fields: id INT(11) auto_increment PRIMARY KEY value VARCHAR(200) Create two records. The next auto_increment id value should be: 3 Dump this table (structure and data) using MySQLAdmin. The next auto increment value (3) will not be included in the CREATE statement. The auto_increment value is not set in the newly created table when you execute the dump in an empty database. SQL INSERT statements could create nasty primary key collisions (duplicate key, for example: id=1) when using the restored database. This prevents correct backup of mysql 4.0 databases or at least makes the restore process rather cumbersome. Thanks for your assistance, Viktor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
