<< Previous chapter (Framework restrictions) | Next chapter (Samples) >>

Troubleshooting

There may be situations, when all seems to be ok, but you're getting unexpected results. For that, you can check this page and see if your case is described here. mysql-unit is just a software, like all other things, so it may contain a bug. If so - then, please, send it and help to improve this project

Session Variables

To maintain nested model for exceptions and for dynamic evaluation of expressions, mysql-unit is using some session variables inside it's core. That causes imminent side-effect on environment, and, therefore, you must be sure that those variables are not used in your system anywhere else.

Before starting test procedure, mysql-unit will check if all of those variables are not used. And, if something went wrong, you'll see:

mysql> CALL TEST_PROCEDURE('DUMMY_PROC');
ERROR 1644 (80600): Environment integrity check failed

This SQL exception code is a sign, that your environment is using some of reserved variables. There is a service table, where all those variables are listed. It's called test_service_variables. Note, that it's named in lower case (so to show that it's for internal usage). Normally, you won't do anything with this table, but it's content is exactly names of variables, which will be checked. The structure of the table is:

• id
  Primary key for the table.
• origin
  Scope, within which variable is used.
• var_name
  Name of the variable
• init_value
  Value, which will be used inside scope when initializing a variable.

So, you should check, what are names of variables, which are used in your installation for mysql-unit:

mysql> SELECT var_name FROM test_service_variables;
+--------------------------------+
| var_name                       |
+--------------------------------+
| @thrown_sqlstate_mysql_unit    |
| @thrown_message_mysql_unit     |
| @thrown_code_mysql_unit        |
| @record_id_mysql_unit          |
| @record_expression_mysql_unit  |
| @record_value_mysql_unit       |
| @record_is_error_mysql_unit    |
| @record_error_code_mysql_unit  |
| @record_thrown_code_mysql_unit |
| @record_error_text_mysql_unit  |
| @statement_mysql_unit          |
| @expression_mysql_unit         |
| @thrown_sqlstate_mysql_unit    |
| @thrown_message_mysql_unit     |
| @thrown_code_mysql_unit        |
| @record_id_mysql_unit          |
| @record_expression_mysql_unit  |
| @record_value_mysql_unit       |
| @record_is_error_mysql_unit    |
| @record_error_code_mysql_unit  |
| @record_thrown_code_mysql_unit |
| @record_error_text_mysql_unit  |
| @statement_mysql_unit          |
| @expression_mysql_unit         |
+--------------------------------+
24 rows in set (0.00 sec)

And after that, you need to decide what to do. You may review your queries or external code and find out where did you use conflicting variables. Non-safe way will be to force release of all used variable. You may do it with:

mysql> CALL RELEASE_FUNCTION_VARIABLES();
Query OK, 0 rows affected (0.00 sec)

mysql> CALL RELEASE_PROCEDURE_VARIABLES();
Query OK, 0 rows affected (0.00 sec)

This will release all variables within function & procedure scope. But be careful - if some of your external logic is using the data in those variables, it may harm your system.

Note, that this problem should never occur, if your code didn't use reserved variables. If you are sure that you are not using those variables, but the code 80600 appeared, then it's probably a bug in mysql-unit.

Reporting a Bug

If you think, that you've found a bug in mysql-unit, then, please, send a feedback via GitHub issues page with "bug" label. Following data will help to resolve the issue:

• Version of MySQL server
• Version of mysql-unit
• What did you do. So what was actions sequence, which caused a bug
• What is the expected result
• What was actual result

Thank you for sending good description for bugs!