MySQL Bugs: #19971: Code generated to edit procedure does not add db name to Create Section

Bug #19971	Code generated to edit procedure does not add db name to Create Section
Submitted:	20 May 2006 15:07	Modified:	19 Jul 2006 11:12
Reporter:	Daniel Fiske	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Query Browser	Severity:	S2 (Serious)
Version:	1.1.20	OS:	Windows (Win XP Home)
Assigned to:		CPU Architecture:	Any

Description:
The code generated when editing a procedure of function does not include database in the create section of the query. This results in the sp/func being created in the default database as opposed the one from where it was deleted.

How to repeat:
1. Create an sp (sp_foo) in the test database.
2. Change default database to another one (call it dbXYZ).
3. Navigate back to "test.sp_foo" and click edit

Code produced is

DELIMITER $$

DROP PROCEDURE IF EXISTS `test`.`sp_foo` $$
CREATE PROCEDURE `sp_foo`()
BEGIN

END $$

DELIMITER ;

4. Execute

Net result is that sp_foo is deleted from test and created in dbXYZ.

Suggested fix:
have edit produced the following code

DELIMITER $$

DROP PROCEDURE IF EXISTS `test`.`sp_foo` $$
CREATE PROCEDURE `test`.`sp_foo`()
BEGIN

END $$

DELIMITER ;

Are you sure you use QB 1.1.20. For me it gives:

DELIMITER $$

DROP PROCEDURE IF EXISTS `test`.`sp_foo` $$
CREATE PROCEDURE `test`.`sp_foo`()
BEGIN

END $$

DELIMITER ;

as a template, exactly as expected. What version of MySQL server do you use?

An example with MySQL 5.0.21 on Win XP/ QB 1.1.20:

right-clicking a Stored Procedure .. choosing edit returns the template

DELIMITER $$

DROP PROCEDURE IF EXISTS `test`.`sp_foo` $$
CREATE DEFINER=`root`@`localhost` PROCEDURE `sp_foo`()
BEGIN
END $$

DELIMITER ;

And another example when connected to a box running Linux - also MySQL 5.0.21:

DELIMITER $$

DROP PROCEDURE IF EXISTS `musik`.`my_p` $$
CREATE DEFINER=`root`@`localhost` PROCEDURE `my_p`()
set @myvar = "We now have GUI support for Stored Procedures in SQLyog" $$

DELIMITER ;

On Linux 'Select version();' returns '5.0.21-max'
On Windows it returns '5.0.21-community-max-nt'

The Linux version in use is the glibc23 RPM build
The Windows version is the (full) installer build.

Tried to submit a screenshot of the QB 'about' screen, but I am not allowed to as I am not the original submitter.

It displays 'Version 1.1.20' !

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Now maybe Daniel did not reply but I did!
Maybe Daniel thought that my replies were sufficient?

This should not have been closed or neglected!

Sorry, I tried several times, with QB 1.1.20 connected to MySQL 5.0.22 on Widndows, and was not able to repeat the behaviour described. Database name is included in all cases.

@Valeriy:

let us take the historey

Daniel opened two bug reports simutanesously that could be related. They were closed automatically because of Daniel's inactivity.  I requested them reopened - mostly because of the other one!  

I do not intend to install old server and QB versions to refresh my memory with details.  Everything is OK doe me too now.

But I do think that some patches regarding the CREATE PROCEDURE statement were done 'silently' (without creating a bug report and without noting of it in the changelogs) between 5.0.20 and 5.0.22.  What has caused a lot of confusion.

Never mind - we have new program version, cannot reproduce anymore, and now it is DEAD!