MySQL Bugs: #7158: Query browser does not handle user defined variables

Bug #7158	Query browser does not handle user defined variables
Submitted:	10 Dec 2004 9:20	Modified:	5 Dec 2008 8:40
Reporter:	Conor Meegan	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Query Browser	Severity:	S2 (Serious)
Version:	1.2.9 rc, 1.1.2	OS:	Windows (Windows XP SP2)
Assigned to:	Mike Lischke	CPU Architecture:	Any

Description:
Query Browser appears not to be able to handle user defined variables at all and returns that the value of the variable is null even after the value has been set.

How to repeat:
I run the following queries in Query Browser;

Set @test1 := 'test1';

Followed by 

Select @test1;

Query Browser returns that the value of the variable is null.

When executed as "query" in the query area, a new connection is opened for each query. Therefore you don't see a temporary table or session variable in the next select/insert. 

The reason for this is, that we need to kill the connection if the user presses
the stop button, as well as to allow several queries on different tabsheets to
be executed at the same time.

If you want to create a temporary table or use session variables, you have to start a transaction or create a script (press Ctrl+Shift+T).

When running:
SET @s:="hi"; (double-quoted)
in a script Window, I get the error:
<< Unknown column 'hi' in 'order clause'. >>
although this is a correct MySQL statement.

But there is no problem with:
SET @s = 'hi';

The version I use is 1.1.3.

But why is it that seting and using a user-variable in the same statement doesn't work either, e.g.,:

SELECT if(@a, @a:=@a+1, @a:=1) as rownum, id from SomeTable;

Situation is still the same. Even if it was designed so, this should be fixed to make QB as useful as mysql command line client. If new connection is needed (I doubt it), then we have to preserver context (user varaibles values, among other things), like in UNIX environment for forked processes.

Bug #26335 was marked as a duplicate of this one.

Bug #26318 (about SP's OUT parameters) was marked as a duplicate of this one. The reason (reconnection for each statement) is the same.

This has been explained several times already. Changing this design requires significant work and time (which currently don't have). A workaround is to start a transaction, which will keep the current session.

This bug's been open for 3.3 years.  Is there time for fixing it now?  The workaround doesn't even work for string variables.

I think it IS NOT a bug. 

On MySQL Browser, click on menu TOOLS, OPTIONS.

Chose the category BROWSER, and on the right pane, mark the option "Show Advanced Toolbars". 

Click on Apply Button and Close.

Now it's appear a new toolbar on MySQL Query Browser.

REMEMBER::: ALWAYS if you run statements on query browser, FIRST CLICK ON TRANSACTION BUTTON from Advanced Toolbars.

No more problems with this will occurs.

Sorry about english!

This problem has now been fixed in our repository by changing how connections are handled. You will get the fix with the next release of the MySQL legacy GUI tools.