[peterlaursen]

I don not understand “… not taking my CC”. Please explain in detail. Can't you register program, or do you have problems logging into Customer Portal?

[peterlaursen]

What are the MySQL server versions involved? Form which version do you exxprot and where do you import.

This ” …ENGINE=MyISAM DEFAULT CHARSET=latin1″ is generated by MySQL 4.1 and higher but is not understood by MySQL 4.0 and lower. That could be the issue! If that is then there are two options:

1) simply remove the above phrase in an editor

2) use our latest beta. It generates a 'backwards compatible backup'.

If that is not the issue, we will need more details. A small test case, preferably. Detailed information of program versions (SQLyog, MySQL servers)

[peterlaursen]

First observations is that if you add tags for each connection it will work. However omitting a tag should be OK, so this must be considered a bug.

Enter the tags like:

Code:

localhost
root **** 3306 [default]
test2

localhost
root **** 3306 [default]
test3

[peterlaursen]

OK .. reproduced now.

I can copy the text from your 'Code box' here and change the details and get the segmentation fault on Fedora3 and SuSE10. If I build a similar jobfile with the wizard on Windows and copy that file to Linux I do not.

Password does not matter. It is reproducable with any password.

We will have to look detailed into this tomorrow.

[peterlaursen]

Not reproduceable here. Testing includes Fedora3, Fedora5, RHEL4 and SuSE10.

I just tried passwords like '123()abc' and similar.

We will need a complete test case or temporary access to your server.

Create a ticket if you have some details you do not want to reveal here.

[peterlaursen]

Quote:

Setting connection charset in connection manager to Big5 can make data input correctly, but they become Big5, not UTF-8.

NO! The setting in the connections manager only specifies the charset for the connection and the client! How it is stored depends on the server/database/table/column charset setting. The MySQL server changes between the charset used for storage and when communicating with the client. The FAQ explains this.

I agree that that is not very intuitive this way. That was why the FAQ was written!

And we will very soon be able to handle Unicode Internally.

Maybe we should not at all display the UTF8 and UCS2 options in connectio manager – but we won't change now!

[peterlaursen]

Quote:

….implement the simple feature i have been requesting for years (“Show Table Data in text”).

Yes, we will. This has been given a priority of '3' on our internal TODO list (scale 1-5).

[peterlaursen]

Reproduced.

Working on the fix now.

[peterlaursen]

Please search a little before asking questions!

This has been answered quite a lot of times before!

This FAQ explains: http://webyog.com/faq/category34.html

Try in the connections manger to choose a chinese non-unicode character set (like 'big5') – and not utf8 – as the character set for the connection. You should be able the display and work with Chinese like that.

However at this very moment coding for Unicode is going on actually! When completed you can have string data using Chinese, Cherokee and Czeck at the same time! This is not possible now. We support languages for which a non-unicode character set in available with MySQL.

To clarify: DATA THEMSELVES can very well be UTF8. If that is the character setting on the server they will also be stored like this, no matter what character set the client uses.

[peterlaursen]

Confirmed that old job files should work.

Also we now can provide a pre-release build with this Debugging concept integrated in SJA if problem persists.

Also can you provide us with a test case?

[peterlaursen]

Quote:

Can we not have sja simply crash?

From next 5.21 beta SJA will use the same debugging concept as SQLyog GUI.

http://www.webyog.com/faq/32_145_en.html

Quote:

Give us a “verbose” mode

Is planned (due to user requests). Personally I do not understand why people want 100.000's of INSERT, UPDATE and DELETE statements.

I will return back with the 'old templates' issue. Nothing should crash with old job files. A few tags have been added, but if they are not there, defaults should be used. But I need to discuss details with developers.

[peterlaursen]

Quote:

So maybe this will work if SQLyog is upgraded to the latest plink 0.58 and keepalives are enabled in the default settings of putty ?

1) the PLINK shipped with SQLyog is our own build. You cannot get it from anywhere else, and can't replace with a 'standard' one. We have compiled in the handles for SQLyog to use.

2) (standard) PLINK uses Putty profiles. Those profiles are encrypted, and we have not been able to find any docs for the format of such profile – so we cannot replicate it! We do not want it to be obligatory to have (and understand) Putty to use SQLyog SSH-tunnelling. SQLyog is a user-friendly GUI-tool! <_< 3) still with tunnelling the 16 0-bit 'keep-alive word' would be tunnelled to MySQL and would cause an error here!

I do not claim it cannot be solved. I hoped that just calling PLINK with a parameter would do, but as it depends on Putty that is not so.

[peterlaursen]

To use tunnelling you'll need the ENTERPRISE version. COMMUNITY version does not support tunnelling.

Please refer to: http://webyog.com/en/sqlyog_feature_matrix.php

[peterlaursen]

Hello!

All your patches have now been integrated in the development tree. You can verify for yourself with the next release.

Thank you!

[peterlaursen]

We cannot do this – and I shall try to explain why. There are two reasons.

1) 'keepalive' is not a configuration itself. It must be allowed for in configuration, but the client must send data at intervals. With Putty simply 16 0-bits are sent (compare a FTP-client that sends the NOOP command). This is enough to tell SSHD that the client is still active.

We could of course code a similar small loop sending the same with a wait(some_seconds) or sleep(some_seconds) command ourselves. However will wil then need to monitor the traffic in the tunnel ourselves (there is no way to get the information form PLINK) as those data should only be sent when no other data are sent.

But the most important reason is.

2) When you connect the common way with Putty you create a remote (and secure) shell. We create a tunnel to MySQL. So those data (16 0-bits or whatever) will be tunnelled to MySQL and not used for the purpose: to keep the connection alive!

[Author]

Posts