[peterlaursen]

Added to our 'wishlist' on our Project Server.

FYI: wishlist contains issues and tasks that are not yet scheduled and not assigned to a specific person or team.

[peterlaursen]

Code:

It would be nice to group tables in a folder just like you currently do it for Stored Procedures, Functions and Views.

I think we heard that some to,es before now! As we soon will start implementing support for EVENTS and PARTITIONS the 'fight for space' in the Object Browser won't become less. I think we should do something serious about that once we finished support for UTF and have started localisations – and at the same time as startingsupporting partions. By the end of this year or so ???

Personally I would like too an option NOT to have VIEWs in a folder as I have one important database where I practically only use the VIEWs and NOT the TABLES. However 95% of users probably still think that TABLES are the important thing. And this option should preferably be per-database-configurable or per-connection-configurable.

Thanks for your suggestion. I suggested this to Ritesh allready when SQLyog 5.0 was developed actually, but it was decided to use the existing code for TABLES at the time.

[peterlaursen]

I think the office in Bangalore has become disconnected now.

It is a seasonal phenomenon (heavy rainfalls that flood the power installations I understand). It normally takes a few hours only but can sometimes last a little longer. Now we have one of the World's biggest UPS's I think so they won't stop working for that reason!

Now if yo do more work on this please throw another .diff!

What are your normal 'working hours' for things like this? Where do you live? A live chat on some details could be useful!

[peterlaursen]

I cannot reproduce!

Please attach a screenshot of the settings dialogue and a small table to reproduce with! Preferably not bigger than it is possible to 'have it in my head'.

What is 'the last' record? The order may depend or what KEYs are in the table and need neot be the same as it is displayed. Please try SELECT COUNT(*), export, import to a test database and repeat SELECT COUNT(*)

[peterlaursen]

All above was MySQL 4.1 and higher.

With 4.0 it is like this. And that is OK. No other encoding than how it is stored.

[peterlaursen]

The 5.18 FREE and 5.2 COMMUNITY edition does not support tunnelling. Only the ENTERPRISE version does.

You can test tunnelling with the ENTERPRISE TRIAL. It is functional for a month.

[peterlaursen]

And this is from SQLyog 4.1 and here 'ÆØÅæøå' have the correct ANSI numbers corresponding to 'latin1' charset and are ONE byte only each.

[peterlaursen]

the statement:

Code:

insert into `nn` (`id`,`english_letters`,`danish_letters`) values ('0','ABCabc','ÆØÅæøå');

as it displays in a HEX-editor with UTF8 box selected and de-selected. Identically. Danish letter are represented by 2 bytes. That is UTF8 encoding in both cases! In Latin1/ANSI those characters are one byte only!

It shall not be if not UTF8 is selected. It shall then simply be a byte-to-byte copy of the stored data!

[peterlaursen]

I do not think this is related to any specific connection type at all!

But when I first started working on it, I thought that it was.

That is the reason for the 'sub-header' reading “.. and HTTP-tunnelling”

[peterlaursen]

Thanks ..

Manoj and the team just arrived at office. Right now they are looking into the 'beta-sillies' that I reported last night. Hope they'll get time to look into this today too!

[peterlaursen]

It would help if you informed about the MySQL version and attached a structure-only dump!

[peterlaursen]

Quote:

DONE:

Like the ability to specify the font for EACH OF THE TABS:

Messages

Results

Objects

History

… that was what we were supposed to work on this week!

Though I personally might think that a setting for EACH of those is too much.

DATA and RESULTs could be the same. Messages and History too.

BTW: do not forget the BLOB-viewer! 🙂

.. I think it would be OK if the settings for DATA also had effect on CREATE/ALTER TABLE etc ..

I hope you will contribute your code – it will of course be included in COMMUNITY!

[peterlaursen]

No there isn't really any easier way. We plan a GUI SQL-builder but most likely won't be this year.

In most uncomplicated cases you can omit the JOIN keyword itself like.

Code:

SELECT table1.DVDTitle, table2.Ratings FROM table1, table2 WHERE ……

Example WHERE with a typical FK-setup (no matter if you use it as CONSTRAINT with InnoDB or not)

Code:

WHERE table1.parent_field = table2.child_field

.. I assume that you have SOME identical info in both tables that identifies each DVD (whether a number or something else!). If you don't you are in trouble …

[peterlaursen]

Now it is working OK on MySQL 4.0.

Also a dump created with SQLyog 4.1 reading like

Code:

/*
SQLyog Enterprise – MySQL GUI v4.1
Host – 4.0.27-nt-max : Database – test
*********************************************************************
Server version : 4.0.27-nt-max
*/

create database if not exists `test`;

USE `test`;

/*Table structure for table `nn` */

drop table if exists `nn`;

CREATE TABLE `nn` (
`id` bigint(20) NOT NULL default '0',
`english_letters` varchar(50) default NULL,
`danish_letters` varchar(50) default NULL
) TYPE=MyISAM;

/*Data for the table `nn` */

insert into `nn` values (0,'ABCabc','ÆØÅæøå');

.. imports OK with 5.18 and 5.2 beta.

Is it really so simple and silly that it we uncheck the UTF8-option then the SET NAMES statement is not added to the file but the data are still encoded?

I am now totally confused! 😮

Fresh eyes on this please!

[peterlaursen]

Now we export WITHOUT the UTF8 -option

File reads like:

Code:

insert into `nn` (`id`,`english_letters`,`danish_letters`) values (0,'ABCabc','ÆØÅæøå');

Executing this from the editor is OK. Importing from a file with the UTF8 options is also OK (as written in previous post).

However importing the file without the UTF8 -option garbles data.

If the file has NO 'SET NAMES' statement it becomes garbage

Also if file contains 'SET NAMES latin1' it becomes garbage

(all defaults are 'latin1' so this is nothing new!)

but if file contains 'SET NAMES utf8' it imports OK.

now 'ÆØÅæøå' is a valid latin1 string ???

and from the editor I can 'SET NAMES' anything where 'ÆØÅæøå' is a valid string (latin1, utf2, ucs2) and it saves OK!

On this system:

Code:

show variables like '%character%';

/*returns

Variable_name Value
———————— —————————————————-
character_set_client latin1
character_set_connection latin1
character_set_database latin1
character_set_results latin1
character_set_server latin1
character_set_system utf8
character_sets_dir C:ProgrammerMySQLMySQL Server 4.1sharecharsets/
*/

[Author]

Posts