Table Dropped When Used Copy Table To Another Database

[aservito]

This is similar to what happened here:

http://forums.webyog.com//index.php?showtopic=4270

As stated in the above topic, it claims or implies to have some fixes for the “copy table” function with the “updated” version as compared to the version the topic starter is using. I'm quite sure the version I am currently using is a lot newer than the said updated version fixed, though I think this would help pinpoint the problem.

In my case, the table already existed on source and target db, my intention was to update the target db, on the interface for starting the copy I had “drop table if exists” checkbox. this could be the source of the bug wherein it dropped not just the table in the target db but also on the source db.

I understand that I may need to update, however if you have not explicitly looked into this issue, the bug should still be there.

I've been using sqlyog for years now, used several versions already and used the copy table function countless of times – first time this happened, good thing that I was on a non critical table that I have a backup of.

Im using SQLyog community v9.20

[peterlaursen]

There has not been any activity on this, except for Friday where we tried for several hours to reproduce this. We cannot. We have never seen this ourselves and have no other reports like this since the one back in 2008. Can you give some hints – for instance:

1) For how long did you have the program open when that happened, and do you remember what operations you had done before that?

2) You are using COMMUNITY version. This only allows for direct connections unless you establish a tunnel of some kind with some other program (Putty/Plink, some VPN software etc.). Do you?

3) Any 'oddities' with database and table identifiers/names (national and rarely used characters)?

4) Are you copying to another server or another database on same server?

5) Anything else about the environment that is non-trivial/unusual you can think of?

Please also tell MySQL server version(s) involved.

'Provoking the error at will' seems quite hopeless as we have tried for hours. The way forward will have to be by code review, I think. However it will be like seeking a needle in a haystack. So if you can reply to above questions it may limit the search to a corner of the haystack.

One possibility is that a specific (and rare) series of operations by user in the GUI causes a DROP statement to be executed before the USE statement,

[Author]

Posts