MySQL Debugging Methods Overview

Introduction
Debugging SQL code is a very important task these days. Unfortunately not all database servers support this feature. And MySQL is one of such servers. In spite of its wide feature set, debugging is not implemented in it. So the problem is that MySQL provides no API functionalities for code debugging. But the necessity to debug SQL code does not disappear and becomes more and more important each year. Some companies that develop tools to access data of MySQL server databases create their own debuggers that solve this problem to some extent.

Types of Debuggers
Now we will consider the types of debuggers that can be implemented for MySQL server and principles of their work.

The first way of debugging stored procedures is to divide their code to separate statements and send each statement separately. This way execution is being emulated, because, for example, the same cycles or branches will be executed not on the server side, but by a client itself. And this brings the accuracy of the debugger work into question.

The second way of debugging stored procedures is that additional control items are placed near every statement. And with the help of these items the procedure execution can be suspended, but in spite of all this the procedure is executed entirely on the server side.

Advantages and Shortcomings of the Debugging Methods
The first method has its advantages and shortcomings. The great advantage is that no additional code is executed at the server side and the code of the procedure is left unchanged. The shortcoming of this method is that the main amount of code is executed on the client side and not on the server side, and that is an emulation of code execution, but not code execution itself. Because of this the result returned after debugging often differs from the result returned by the server after executing the procedure. And this situation is worsened by the fact that the result of code execution can differ depending on the MySQL server version. For example, in MySQL 4.1 “NOT” and “!” operators have identical priority, but in the version 5.0 and higher the priority is different, and it is impossible to take into account all such nuances. That’s why such debugger will return the same result on different server versions, because it will not take into account all refinements of code execution on different servers, and instead will interpret the code on its own.

The advantage of the second method is that the procedure is executed on the server completely, and this guarantees 100% correct result of debugging. Client does not interpret anything and all execution process is controlled by server. That’s why problems associated with different MySQL server versions are not topical for this kind of debugger. But one should “pay” for the high quality of such debugger, because its main shortcoming is that extra operations should be performed to add control items into the procedure body, even in spite of the fact that these items can be easily added and easily deleted.

Conclusion
One should decide on his or her own what kind of debugger is better for him or her. dbForge Studio for MySQL could not allow a user to get wrong results during debugging and that’s why it chose the second method and created a server side debugger. It sacrificed the convenience to some extent, but gained a great advantage in the accuracy of the debugging results.