[peterlaursen]

1) Are you sure that you did not change the password? Please try (if you did not) to create a new connection in SQLyog user manager.

2) Also are you sure that connection from remote hosts are allowed for root user?

[peterlaursen]

We have replied in you ticket already. What is the idea in contacting us twice?

We replied:

You do not provide enough information.

* What is the SQLyog version you are using?

* What is the exact MySQL version. “5” can be anything from 5.0 to 5.6 (and there is * almost 10 years between them). Please execute “SELECT VERSION();”

* How do you connect from SQLyog? direct connection? SSH tunnel? HTTP/tunnel?

* Do you have a setting in MySQL configuration like 'OLD_PASSWORDS'?

The 16-character hash was used as default by MySQL up to and including version 4.0. From 4.1 the 41-character has is default. There is only one reason to use the 16-character hash ('OLD-PASSWORDS') with recent servers if you need it for compatibility with old clients (such as PHP 4.3 and earlier). The 16-character hash is not very secure.

SQLyog should be able to handle both, however. What is the exact error you get when trying to connect? 'Access denied' or 'Connection denied'?

[peterlaursen]

“This backup includes the aforementioned table, however a modified version with only 650K rows.”. Are you telling that the dump of this particular table is incomplete or did you delete rows in between?

There should not be different methods for generating the SQL.

The problem is that we are uncertain if we understand all what you are telling. We would like to see it happen before our own eyes and would ask for a shared session with you. It will be dificult to do progress without. Could you please send a mail to [email protected] so that we can arrange this in private?

[peterlaursen]

Actually you (we) cannot DROP and ADD a FK-CONSTRAINT in a single statement. Even though I think the the server should return a regular syntax error in such case, we will have to fix it in our code – and we are doing now.

[peterlaursen]

It is the type of indexes on the tables that defines if it is one-to-one or one-to-may etc. If there is a UNIQUE CONSTRAINT of any kind (Primary Key, Unique Index) it will be 'one'. If there is no UNIQUE CONSTRAINT it will be 'many'.

Where do you expect an icon?

[peterlaursen]

Well .. we are stuck and don't know how to do progress here. But MySQL 5.5.15 is now pretty old and you could consider to upgrade to 5.5.29 (latest 5.5 available). But only the exercise itself can tell if it has anything to do with what we discuss here.

[peterlaursen]

You shall not do anything. I believe it is a server bug and I have reported it here:

http://bugs.mysql.com/bug.php?id=68286

You can drop + add constraints manually from GUI, because it will generate two ALTER TABLE statements. But if you drop + add in one ALTER TABLE statement you get this error.

Let us wait for the reply from MySQL before we decide if we should generate two ALTER TABLE statements in the script. We would like not to for performance reasons.

[peterlaursen]

Still it is not reproducible here with neither SQLyog 10.51 nor 11.0 beta 2. We inserted 5 mio. rows to a table with your table definition. There is no slowdown after a while as you experience and the result arrives in 30 seconds.

We are using MySQL 5.5.18 64 bit. What is the *exact* server version you use (“SELECT VERSION();” will tell)? Yours is older/newer? 64 bit or 32 bit?

[peterlaursen]

* Can you share the table structure on target before running the sync script was executed as well as the complete sync script?

* Now if you try again is it still reproducible? Also after MySQL is restarted?

This

Error Code: 1005

Can't create table 'cams_kpn.#sql-794_dc4' (errno: 121)

.. is a server error that tells that the server was not able to create an internal temporary table required to process the statement. The same server error would probably have occured with any client executing the same statement. And the statement is valid (as no error 1064 is returned). There are lots of bugs reported with specific server versions resulting in this. There could also be temporary locking issues or the temporary table could require more diskspace than what is available in /tempdir.

So:

* Also please tell the MySQL server version (also target).

* If you have acces to do so, try to cleanup the /tempdir (“SHOW GLOBAL VARIABLES LIKE 'tmpdir';” will tell you what folder MySQL uses as /tempdir). Sometimes you will find a lot of orphaned temporary files there consuming a lot of diskspace.

[peterlaursen]

BTW: also tell if you are using tunnelling. In particular with HTTP-tunnelling to a remote and shared server there could be some restrictions on large transfers in the networking settings on the remote systems.

[peterlaursen]

Also if you you send you MySQL configuration (my.cnf/my.ini) it might help. There could be a specific configuration setting. Is this a server you manage yourself or a shared server?

[peterlaursen]

“otherwise the first rows would be just as slow”. Why do you think so? There can be buffer/cache issues lots of places (in MySQL, on the remote network or whatever). Anyway we will check this.

[peterlaursen]

1) Are you sure it is not a server slowness you are encountering? The can be several server configuration setting affecting this. Is another client installed on same machine as SQLyog faster?

2) What are your BULK and CHUNK settings Refer http://faq.webyog.com/content/24/101/en/about-chunks-and-bulks.html

3) What happens to the client machine's memory consumption? Does it increase for the SQLyog process and has the system atarted swapping? Please check in Task manager.

[peterlaursen]

If you don't find the sqlyog.ini it could be because it is stored in a hidden folder (user's 'AppData' folder) with Windows default setting.

It is/should be here (on Windows Vista or higher): {System_drive}:Users{user}AppDataRoamingSQLyogsqlyog.ini. To unhide the AppData folder go to control panel .. folder settings and check 'show hidden folders'.

However since SQLyog cannot display connections, the file is either not there or it is corrupted/unusable. If you are using WIndows 7 or higher and have 'System Restore' turned on you may restore the complete folder C:UsersPeterAppDataRoamingSQLyog. Just navigate to it from WIndows explorer, right-click, select 'properties', go to 'previous vesions' tab and select a 'shadow copy' from before this happened for restore (make a copy of the existing folder first just in case ..) for restore. If you have a backup of the complete system or of your 'user profile' you may of course also restore from there.

As the sqlyog ini is user-specific it will not be found it you login to the system with another user account than what was used when it was created.

One possible reason for this could be that some 'security software' has quarantined or deleted the file. Or some 'malware' could have deleted or corrupted it. If you find the file in its position you may send us to us privately to [email protected] as we would then like to know why SQLyog is not able to use it.

[peterlaursen]

The simple explantion is that the TRIAL has expired for one user but not for the other. Just as the license for commercial versions is *per user* the TRIAL period also is *per user*.

[Author]

Posts