From Jonathan Miller The sample output below show several different error number types. We have NDB errors, MySQL errors and SQL State errors. After a user has been working with MySQL for a while they might begin to be able to tell which error is from what part, but not until you have had to fight with it for a while. You have: * Error_code * Got error * errno * server_errno I don't find this to be user friendly or even well documented. And with new storage engine coming I can only see if getting worse. Suggestion Short Term: My Short term suggestion is that we document what is what. i.e. Error_code = SQL State and errno = mysql, etc... Suggestion Long Term: That we open a work log and change the numbering to include a prefix i.e. MySQL_ERROR: #### NDB_ERROR: #### SQLSTATE_ERROR: #### FALCON_ERROR: #### Etc, From Roland Bouman, Certification Developer I can confirm that Oracle adheres to such a system. Some prefixes: TNS: network protocol related problems PLS: problems in the stored procedure (PL/SQL) extension engine (that's because they have several execution environments for PL/SQL) ORA: Oracle server error messages. could be ordinary SQL errors, or physical problems such as resource shortages. From Hartmut on IRC hartmut|around jeb: you only forgot to mention all those "internal server errors" >1000 we expose to the client side all the time ... without resolving them with perror From Kaj Concur 100 % that this needs to be cleaned up! I would welcome it if you wrote up a suggested worklog item, and then got it approved by Trudy & Brian. Replication Requirements -------------------------------------------------------------- The binary log contains the error code of each executed statement (O if no error). The slave needs to mimic this error code to allow replication to continue. So: 1. All error codes resulting from statement execution needs to be loggable in the binary log. (In 5.1 and below the error code is coded as 2 bytes in query_log_event. Changing this to e.g. 4 bytes means either creating a new query_log_event log event type or increasing the binlog version number.) 2. There needs to be an easy way to interpret the error code stored in the binary log to see why a statement failed on master but succeeded on slave (or the opposite). (The above are very simple requirements to satisfy. They are just listed here so that they are not forgotten.) Note added by Trudy Pelzer, 2006-08-28 During a discussion between Brian Aker, Calvin Sun, Elliot Murphy and me today, the decision was made that it's too late to do this work for MySQL 5.1. -- end note Client-server protocol note: ------------------------------- Instead of encoding the source of an error in the error message text, we should add a separate field in the client-server protocol for the source. This is one of many attributes of an error, and we already treat errors as composite objects, containing error code, error message, sqlstate. See also BUG#17034 "Error messages from stored routines should name their source".