How to Report Bugs or Problems means better for us. If you have data that you do not want to be visible to others in the bug report, you can upload it using the Files tab as previously described. If the information is really top secret and you do not want to show it even to us, go ahead and provide an example using other names, but please regard this as the last choice. •Include all the options given to the relevant programs, if possible. For example, indicate the options that you use when you start the  mysqld  server, as well as the options that you use to run any MySQL client programs. The options to programs such as  mysqld  and  mysql , and to the  configure  script, are often key to resolving problems and are very relevant. It is never a bad idea to include them. If your problem involves a program written in a language such as Perl or PHP, please include the language processor’s version number, as well as the version for any modules that the program uses. For example, if you have a Perl script that uses the  DBI  and  DBD::mysql  modules, include the version numbers for Perl,  DBI , and  DBD::mysql . •If your question is related to the privilege system, please include the output of  mysqladmin reload and all the error messages you get when trying to connect. When you test your privileges, you should execute  mysqladmin reload version  and try to connect with the program that gives you trouble. •If you have a patch for a bug, do include it. But do not assume that the patch is all we need, or that we can use it, if you do not provide some necessary information such as test cases showing the bug that your patch fixes. We might find problems with your patch or we might not understand it at all. If so, we cannot use it. •Guesses about what the bug is, why it occurs, or what it depends on are usually wrong. Even the MySQL team cannot guess such things without first using a debugger to determine the real cause of a bug. •Indicate in your bug report that you have checked the reference manual and mail archive so that others know you have tried to solve the problem yourself. •If your data appears corrupt or you get errors when you access a particular table, first check your tables with  CHECK TABLE . If that statement reports any errors: •The  InnoDB  crash recovery mechanism handles cleanup when the server is restarted after being killed, so in typical operation there is no need to “repair”  tables. If you encounter an error with InnoDB  tables, restart the server and see whether the problem persists, or whether the error affected only cached data in memory. If data is corrupted on disk, consider restarting with the innodb_force_recovery  option enabled so that you can dump the affected tables. If we cannot verify the exact purpose of the patch, we will not use it. Test cases help us here. Show that the patch handles all the situations that may occur. If we find a borderline case (even a rare one) where the patch will not work, it may be useless. •For non-transactional tables, try to repair them with  REPAIR TABLE  or with  myisamchk . See Chapter 5,  MySQL Server Administration . •If you often get corrupted tables, you should try to find out when and why this happens. In this case, the error log in the MySQL data directory may contain some information about what happened. (This is the file with the  .err  suffix in the name.) See Section 5.4.2, “The Error Log” . Please include any relevant information from this file in your bug report. Normally  mysqld  should  never  corrupt a table if nothing killed it in the middle of an update. If you can find the cause of  mysqld  dying, it is much easier 75 If you are running Windows, please verify the value of  lower_case_table_names  using the  SHOW VARIABLES LIKE ’lower_case_table_names’  statement. This variable affects how the server handles lettercase of database and table names. Its effect for a given value should be as described in Section 9.2.3, “Identifier Case Sensitivity” .