forums › forums › SQLyog › SQLyog: Bugs / Feature Requests › Important Bug: Importing .sql Mess!
- This topic is empty.
-
AuthorPosts
-
-
January 18, 2007 at 3:44 pm #10133MarkoMember
Okay, I was just about to delete this piece of software, since this is the 2nd time (with 2 different versions) this happened:
I was using database X. Then, I opened database Y, deleted all tables (empty) and clicked to import .SQL file. It only includes DROP, CREATE and INSERTS. Even though my selected DB was Y and so was it selected on top of program, the damn thing started importing it into DB X, dropping an important table, which now I have to rebuild, thank you very much. Anyway, here is my bug report, if you need more info, do tell, but please fix this, before someone else deletes one of framework's most important table.
-
January 19, 2007 at 1:26 pm #23245peterlaursenParticipant
Is there a USE statement in your file. If so the database specified with the USE statement will be USED …
-
January 22, 2007 at 11:00 am #23246MarkoMember
No, I thought about that too so I checked, but there is no USE command, just drop/create table commands and inserts.
-
January 22, 2007 at 12:37 pm #23247peterlaursenParticipant
OK then.
1) Program version please?
2) could you possibly submit a 'test case'? How to reproduce?
3) When you “select a database” do you then do this by clicking a database in the Object Browser (the left area) or do you use the dropdown combo?
-
January 22, 2007 at 1:25 pm #23248peterlaursenParticipant
BTW: does the file use 'full syntax' like
Code:`database`.`table`or
Code:`table`only when referencing a table?
-
January 23, 2007 at 1:44 pm #23249MarkoMemberpeterlaursen wrote on Jan 22 2007, 02:25 PM:BTW: does the file use 'full syntax' likeCode:`database`.`table`
or
Code:`table`only when referencing a table?
Previous question: I was using 1st database for some project, then closed it and clicked on 2nd one, rightclick -> Empty database. it dropped all tables from 2nd database, which is ok. The dropdown on top of program was still showing 2nd database and it way selected in treeview. So I clicked on IMPORT (I imported the SQL) but it used 1st database.
Second: this is part of .SQL I was importing:
Code:—
— Host: localhost Database: renderspace2
— ——————————————————
— Server version 5.0.22-log/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;—
— Table structure for table `_contents`
—DROP TABLE IF EXISTS `_contents`;
CREATE TABLE `_contents` (
`id` int(11) NOT NULL auto_increment,
`id_page` int(11) NOT NULL default '0',
`id_module` int(11) default '0',
`id_module_type` int(11) default '18',
`id_position` int(11) NOT NULL default '0',
`id_state` int(11) default '8',
`lng` varchar(3) collate utf8_slovenian_ci NOT NULL default 'sl',
`title` varchar(255) collate utf8_slovenian_ci NOT NULL,
`ord` int(11) NOT NULL,
`inherit` int(11) NOT NULL default '0',
`lead` text collate utf8_slovenian_ci NOT NULL,
`content` text collate utf8_slovenian_ci NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_slovenian_ci;—
— Dumping data for table `_contents`
—etc…
This is the second time this happened to me in last 2 weeks, that's why I reported this. I've used mysqlfront and other programs before sqlyog and this never happened to me before. I can try and reproduce this, but can't do before tomorrow (totaly busy), since I wanna be careful, I have few big and important databases and losing any data would be a disaster 🙂 Will let you know.
-
January 23, 2007 at 2:49 pm #23250peterlaursenParticipant
Still not reproducable but there is an nonexpected behaviour with the focus in the Object Browser.
Quote:I was using 1st database for some project, then closed it and clicked on 2nd one, rightclick -> Empty database. it dropped all tables from 2nd database , which is ok. The dropdown on top of program was still showing 2nd database (see note below) and it way selected in treeview. So I clicked on IMPORT (I imported the SQL) but it used 1st database.Still I have in HISTORY after (see note below):
use `first_database`
…
use `second_database`
.. and import is done to second database as it should
Note:
What we see now is that the focus behaviour is different when the table tree of a database is expanded or not. Also 'empty database' and 'truncate database' behaves differently.
1) create table `ppp`
2) create table `qqq`
3) let `ppp` be your 'first database' and `qqq' be your 'second database'
What happens at the point of (see note below) in your description is that
4) First expand `ppp` and see that
* if the tree of `qqq` is expanded when emptying it, focus does not change from `qqq`
* if the tree of `qqq` is not expanded when emptying it, focus does change to `ppp`
* with 'Truncate database' focus never changes.
5) Next 'collapse' both `ppp` and `qqq` and repeat. Now focus changes to the connection.
This was tested with 5.23 beta1. Your exact version?
Additional questions:
Is this always reproducable or does it only happen from time to time?
Can you see the latest USE statement sent by SQLyog in HISTORY?
Is there a server log that can tell if this USE statement was received by the server?
Connection type and quality?
We had a similar report about 1/2 year ago. We were not able to reproduce either. We would very much like to get to the bottom of this – be it a SQLyog issue or not. Are we missing something?
The old discussion is this one:
http://www.webyog.com/forums//index.php?sh…43&hl=wrong
(a lot of irrelevant posts in here, but it started similar to your issue here)
Please reply to as many questions as you can. We will then discuss what we can possible do …
-
January 23, 2007 at 3:17 pm #23251peterlaursenParticipant
BTW: there is no issue with your mouse?
Again check the USE statements in HISTORY.
-
-
AuthorPosts
- You must be logged in to reply to this topic.