[peterlaursen]

Let me also add that since MySQL 5.6 introduced the option to define “ON UPDATE CURRENT_TIMESTAMP” to every TIMESTANP or DATETIME column of a table, this has not become less complicated. Before 5.6 only one TIMESTAMP column could use the “ON UPDATE CURRENT_TIMESTAMP” flag.

[peterlaursen]

One more point: you may use HTTP-tunnel or SSH-tunnel with SQLyog and you will also technically connect from 'localhost'.

[peterlaursen]

I don't know much about Python, but are you sure that Python does not use the Python runtime on the server for the connection (and thus technically connects from 'localhost')?

Please try with 'mysql' command line tool, Workbench or one of our competitors.

Besides the SQLyog version you are using is now rather old, and it there is an issue here it is all history. We cannot fix anything in old versions. They are as they are. But I doubt that it will make any difference with current version.

[peterlaursen]

We neither can nor will make this work quickly.

It is already in our issuetracker http://code.google.com/p/sqlyog/issues/detail?id=409 but there is no guarantee that it will ever be implemented.

[peterlaursen]

It works fine here. This is an issue with your system. I think we had this reported recently and we are looking up details.

First step could be to try to reboot the system!

[peterlaursen]

I have added this in this context (as I proposed):

http://code.google.com/p/sqlyog/issues/detail?id=813

I do not guarantee that it will ever be implemented.

[peterlaursen]

Fixed in 11.22 released today: http://blog.webyog.com/2013/08/19/sqlyog-mysql-gui-11-22-released/

[peterlaursen]

It is not reproducible here. If I close SQlyog in maximized state it also opens in maximized state

There must be some content of your sqlyog.ini causing this. We will follow up after the weekend. But if you locate the SQLyog.ini (on recent WIndows (Vista and later) the path is C:Users[user]AppDataRoamingSQLyog), please try to rename it and start SQLyog again. Does it still happen? (Be aware that stored connections and other settings are lost, so don't delete the file. We may also want to check it)

Also please tell: for how long have you been using (various versions of) SQLyog on that particular system? If it has been for many years there may be some incompability enherited from an old version (even though every SQLyog version released *should be* compatible with the SQLyog.ini originally created by any older version).

[peterlaursen]

Hmmm .. I am not sure this is meaningful for a GUI client. It looks rather like some scripting.

Anyway .. please tell: are the databases on the same server/connection or are the databases on different servers/connections?

If they are in the same connection I think it can be considered in this context: http://code.google.com/p/sqlyog/issues/detail?id=813 ?

If they are on different servers/connections do you expect it to work even if there are not open connections to all servers in SQLyog?

[peterlaursen]

hmmm .. I am not sure I understand fully.

But if you create a structure-only copy and on the copy rename a table or column the Schema Sync tool cannot know (for instance) that 'table1'¨should be replaced with 'table2' whne syncing copy>>original. 'table1' wil be dropped and a new 'table2' created and all data in 'table1' will be lost. Same for columns.

The sync tool can only see that one table exists on source and not on target (and vice versa). It cannot read you intention that you wanted to RENAME an existing object (table or column).

What I would suggest instead is:

1) make a structure-only dump and import somewhere else

2) use SQLyog GUI to make all schema changes to the structure on the copy

3) HISTORY tab will record all SQL statements, You can copy from here and the result will be a script that can be executed against the original database.

[peterlaursen]

However also refer http://dev.mysql.com/doc/refman/5.1/en/show-index.html

Quote:

Cardinality

An estimate of the number of unique values in the index. This is updated by running ANALYZE TABLE or myisamchk -a. Cardinality is counted based on statistics stored as integers, so the value is not necessarily exact even for small tables. The higher the cardinality, the greater the chance that MySQL uses the index when doing joins.

Note the use of the term 'estimate'. Thre are a lot of metadata in InnoDB that are estimates and not exact values. Even SELECT COUNT(*) returns an estimate in InnoDB with large tables (or at least did some years ago).

So maybe you could try to ANALYZE TABLE on that table (http://dev.mysql.com/doc/refman/5.1/en/analyze-table.html). As far as I understand this will 'recount' the cardinality and update the ESTIMATE. However I am not sure that you will get exact values with InnoDB.

If you think you found a bug in the server you should report to http://bugs.mysql.com/ (but one advice: first upgrade server to latest 5.1 – 5.1.71 that is currently. At http://bugs.mysql.com/ they will most likely ask you to do so before considering a bug report.

[peterlaursen]

This is not the best question to ask such question. A better place would be http://forums.mysql.com/.

You are welcome to ask here though – hoping that other users will reply. But please understand it we at Webyog have no obligation to reply to htis. We support our own products (SQLyog and MONyog) and not the MySQL server or any other product from Oracle etc.

[peterlaursen]

Am I right that this was a request for SQLyog and not MONyog?

[peterlaursen]

Was this meant for MONyog or for SQLyog?

[peterlaursen]

Please read: http://blog.webyog.com/2013/08/09/sqlyog-mysql-gui-11-21-released/

[Author]

Posts