[peterlaursen]

Confirmed with 5.1 beta2.

Is that the version that you are using too?

[peterlaursen]

@ritesh.

I am happy to hear that! But what can I do?

[peterlaursen]

I don't know about 'standards'. My Opera Browser can be configured to show a close button on each tab. That's nice actually.

But if I understand correctly, then it will never be possible to close a tab in that pane. I so I don't think the X should display at all. But absolutely not important, I think! But actually I think it would be better to be able to close down (and hide!) a RESULT-tab.

[peterlaursen]

QUOTE

I think MySQL is case sensitive by default in Linux.

Sure. If lower_case_table_names directive is omittted in configuration file it takes its value from lower_case_file_system. As 99.9 % of *nix (except for Mac) uses a case-sensitive file system and as most peple don't change the default, that is the way it is.

[peterlaursen]

BTW: I would prefer that the X was on the tab itself!

[peterlaursen]

Quote:

Full configuration about the CHUNK behavior has already been implemented in BETA 3 development tree.

That is nice. Did you make BULK size configurable at the same time then? 🙂

[peterlaursen]

@ ritesh

But it does not work as you describe it here either. See attached. In this situation it should be possible to close the active RESULT tab. Right?

But X is 'greyed out'.

[peterlaursen]

It depends on the directive lower_case_table_names in the mysql configuration.

If this is = 0 (as most often on *nix) a simple rename table will do. if it is 1 then of course not possible. If it is 2 (as most often on Windows and MAC) you can use this trick (use 2 'rename tables'):

CODE

rename table `test`.`t1` to `test`.`dummy`;

rename table `test`.`dummy` to `test`.`T1`;

[peterlaursen]

1) It works here with 5.1 BETA 2

2) Confirmed. It is always 'greyed out' The X should close one single tab. Not the pane if I understand correctly. But it is not available with 5.1 BETA either. The X should be active when a RESULT tab is selected.

[peterlaursen]

1)

Quote:

I'v found something : If I connect to local dest server w GUI and run this query 'SET NAMES latin1'

afterwards

I can change (UPDATE/INSERT) spec characters … and it seems good. How can I applicate this into syncronization ?

I am afraid it only seems to work! Those special characters will only bed read correctly by SQLyog. Any client that read the data corrrectly as UTF will not read the correct caracters. SQLyog insert wrong data, but 'reverses' the error when reading. Just as is the case when inserting localized object names into the Embedded database with 5.1 version.

2)

You cannot edit the tunnelling file this way! Dus to the nature of the HTTP-protocol SET NAMES must be done for each SQL-statement. Actually there is a set_names() function in the tunnelling file allready. You can edit this.

3)

Quote:

Could you help me ?

We have been disucssing this for more than a month now since it became obvious that there was a problem. As I wrote elsewhere, I believe that the only solution is that SQLyog communicates with the tunnelling file in UTF-8. Then a ANSI<>UTF coverter library (supporting ALL ANSI localisations) must be included with SQLyog.

I am afraid that I personally can't do more now.

4)

There is no chance that you can hve direct connection or SSH-tunnel to the server?

[peterlaursen]

I think there is. You raised the CHUNK size to 1000 rows. It is now only about 2 times slower than 5.02 when backing up the FAQ database.

To be fully usable it should be configurable!

[peterlaursen]

Just let me add that the primary reason for this is that RESULT pane may display colums from more tables (when using a SELECT … JOIN (implicit or explicit JOIN) statement). There might even be identically named columns with identical datatypes. So this protects against updating the wrong table.

[peterlaursen]

I don't know then.

Do you have the chance to test with another PC?

Does 5.1 beta2 does the same thing?

[peterlaursen]

Two more FAQs:

http://www.webyog.com/faq/8_99_en.html

http://www.webyog.com/faq/29_100_en.html

[peterlaursen]

@sarat

'verified just as you described it' as MySQL use to express themselves. Works great now. Thanks 😀

Now just a green 'u' icon for user strings and write to Embedded database as UTF-8 ..

[Author]

Posts