[peterlaursen]

It has been released now. Please refer: http://blog.webyog.com/2013/06/11/sqlyog-mysql-gui-11-12-released/

[peterlaursen]

I am not an expert in this type of network. We don't use Windows domain servers systems. There is no other option (such as the ip)?

But you can install on the server of course.

[peterlaursen]

Of course SQLyog cannot connect if server is not running. And the problem with MySQL is unrelated to SQlyog.

So I do not understand why you post this here?

[peterlaursen]

I think the problem could be related to this:

http://code.google.c…s/detail?id=907

We don't have an option to HEXDUMP binary data and a dump with such data may garble in a UTF8-editor if it contains byte sequences that are not valid UTF8 characters. This affects the SQLyog editor as well. But from tools .. execute sql script -menu it should work.

Please provide a small dump that illustrates the problem so that we can verify if this is the problem.

[peterlaursen]

Maybe also you could simply try to clear the browser cache?

[peterlaursen]

I wonder if it could be sql_mode related?

What is the server's global mode? (execute “SHOW VARIABLES LIKE 'sql_mode';”)

Could you try to execute “SET SQL_MODE = '';” and then repeat (if empty mode is not global for the server)?

[peterlaursen]

Please tell the exact server version you are using. I wrote about a similar case here: http://blog.webyog.com/2012/07/06/what-were-the-conditions-and-what-is-the-fix/ (and this is a server bug).

SQLdumps from SQLyog do not contain UPDATE statements (I cannot think of any case where it does), but you could still have bumped into a variation of this bug.

Will you be able to share the SQL dump with us?

[peterlaursen]

we are strugggling with an issue in a new feature (http://code.google.com/p/sqlyog/issues/detail?id=827) that we need to solve before we can release 9.1 beta. It is somewhat unpredictable if it will take 3 hours or 3 days. So the best I can say now is: end of this week or beginning of next.

[peterlaursen]

Same issue with the variants:

SELECT * FROM `table`

WHERE t='– Object'

LIMIT 200

;

SELECT * FROM `table`

WHERE t='/* Object */'

LIMIT 200

;

.. a “LIMIT 0, 1000” is added where it should not.

[peterlaursen]

Confirmed. It is not related to escaping but to the hash-character (#)

— executed

SELECT * FROM `table`

WHERE t='#Object'

LIMIT 200

;

— history

SELECT * FROM `table` WHERE t='1#Object'LIMIT 200 LIMIT 0, 1000;

So it seems our detection for a user defined LIMIT does not look after the '#' (you probably know that '#' is a comment specifier. But here it is not as it is inside a 'quoted string'). Such issues we fix as soon as they are discovered, of course.

[peterlaursen]

I have tried a few simpler test cases but did not find anything that broke yet. Now if you write the statements like:

SELECT * FROM web_js_error_log

WHERE addeddatetime >= '2013-03-10 00:00:00'

AND description=”Uncaught TypeError: Property 'undefined' of object # is not a function”

LIMIT 200

;

or

SELECT * FROM web_js_error_log

WHERE addeddatetime >= '2013-03-10 00:00:00'

AND description='Uncaught TypeError: Property 'undefined' of object # is not a function'

LIMIT 200

;

.. do they still fail?

[peterlaursen]

Well .. we add a LIMIT clause (with a parameter according to user's paging setting) to statements executed from the editor if there is no one specified.

It seems that we don't detect the user defined LIMIT in this case. Probably because of the ” '' ” escaping sequences.

We will check.

[peterlaursen]

Should not be problem. SQLyog works with MySQL versions from 3.23.x. Operating systems don't matter at all.

With SQLyog just open a connection to each server. From the connection to the 4.0 server right-click the database and select 'Copy database to other host/database'. Create the database to import to of 5.1 in advance. Note that 5.1 has a 'default character set' setting on the database level (4.0 only has on the server level). Choose the one that matches the encoding of you data (what will most likely be 'latin1' as 4.0 did not have utf8 or other unicode options)

If you have more database on the server you repeat the step for each database. Or simply dump/export and import.

[peterlaursen]

From the menu .. tools .. execute SQL script.

The .sql file may or may not have CREATE DATABASE and USE DATABASE statements. If not create an empty database in advance.

[peterlaursen]

Actually everything is even more clear from this error message: “Column count of mysql.proc is wrong. Expected 20, found 16. Created with MySQL 50096, now running 50528”

The server was upgraded from version 5.0.96 to 5.5.28. In 5.0.96 the `proc` table has 16 columns. In 5.5.28 it should have 20. But on this server it only has 16 because of incorrect upgrade procedure.

Now: there is a problem: you cannot upgrade from 5.0x to 5.5x in one step. At least it is not guaranteed to work (but you should still try if running mysql_upgrade fixes the probelm, of course). But if even mysql_upgrade errors, is a problem that the server admin (whether it is you or another person) must fix. There is nothing wrong about what SQLyog does here.

[Author]

Posts