How to Report Bugs or Problems (including the platform type and version number). These are highly relevant pieces of information, and in 99 cases out of 100, the bug report is useless without them. Very often we get questions like, “Why doesn’t this work for me?”  Then we find that the feature requested wasn’t implemented in that MySQL version, or that a bug described in a report has been fixed in newer MySQL versions. Errors often are platform- dependent. In such cases, it is next to impossible for us to fix anything without knowing the operating system and the version number of the platform. If you compiled MySQL from source, remember also to provide information about your compiler if it is related to the problem. Often people find bugs in compilers and think the problem is MySQL-related. Most compilers are under development all the time and become better version by version. To determine whether your problem depends on your compiler, we need to know what compiler you used. Note that every compiling problem should be regarded as a bug and reported accordingly. If a program produces an error message, it is very important to include the message in your report. If we try to search for something from the archives, it is better that the error message reported exactly matches the one that the program produces. (Even the lettercase should be observed.) It is best to copy and paste the entire error message into your report. You should never try to reproduce the message from memory. If you have a problem with Connector/ODBC (MyODBC), please try to generate a trace file and send it with your report. See How to Report Connector/ODBC Problems or Bugs. If your report includes long query output lines from test cases that you run with the  mysql  command- line tool, you can make the output more readable by using the  --vertical  option or the  \G  statement terminator. The  EXPLAIN SELECT  example later in this section demonstrates the use of  \G . Please include the following information in your report: 73 •If a database table is related to the problem, include the output from the  SHOW CREATE TABLE db_name . tbl_name  statement in the bug report. This is a very easy way to get the definition of any table in a database. The information helps us create a situation matching the one that you have experienced. •If  mysqld  died, you should also report the statement that caused  mysqld  to unexpectedly exit. You can usually get this information by running  mysqld  with query logging enabled, and then looking in the log after  mysqld  exits. See Section 5.9, “Debugging MySQL” . •If the problem occurs during compilation, include the exact error messages and also a few lines of context around the offending code in the file where the error occurs. •If you are using a source distribution of the MySQL software, include the name and version number of the compiler that you used. If you have a binary distribution, include the distribution name. •The contents of the  docs/INFO_BIN  file from your MySQL installation. This file contains information about how MySQL was configured and compiled. •Sometimes the amount of memory (real and virtual) is relevant. If in doubt, include these values. •The operating system name and version. If you work with Windows, you can usually get the name and version number by double-clicking your My Computer icon and pulling down the “Help/About Windows” menu. For most Unix-like operating systems, you can get this information by executing the command uname -a . •The manufacturer and model of the machine on which you experience the problem. •The version number of the MySQL distribution you are using (for example, MySQL 5.7.10). You can find out which version you are running by executing  mysqladmin version . The  mysqladmin  program can be found in the  bin  directory under your MySQL installation directory.