This was a new variation, I think! You can look around in the Forums and find other variations.
I tried if an empty sqlyog.ini would crash 5.11 and 5.12 BETA3 on my system and it does not. If there is an empty (or no) sqlyog.ini SQLyog writes this:
[HSplitter]
Left=0
Right=0
Top=0
Bottom=0
ULeftOrTopPercent=0
[VSplitter]
Left=0
Right=0
Top=0
Bottom=0
ULeftOrTopPercent=0
[SQLYOG]
Left=0
Top=0
Right=600
Bottom=600
.. and next displays the connection screen. If you save details here they are saved too and main program window opens.
From the information from another user we have seen a crash occur after the creation of the sqlyog.ini -file (as an empty file) and before writing anything to it.
Hmmm.
Empty sqlyog.ini's, empty 'favorites' folder, favorites-files with an empty extension can crash some systems. Every time we come back to the file system.
BTW .. I also think that the backup tools should soon allow for backup of EVENTS with MySQL 5.1 – partiotions are backed up allready as they are returned with the 'create statement for the table'.
I don't request full-blooded support for events at this time. Only in the backup tools in 'the first run'.
1) First I notice that there is no Primary Key in the table. You should *NOT* attempt to use SJA without understanding how it uses the Primary Key and what is does it there is not any! You might get quie another result than you expect! The article explains. If possible: add a Primary Key.
2) Need they all be TEXT? 'clientip' could be a char/varchar(15) I think? You may run into a MySQL configuration issue (buffers too small) that makes it very slow to execute the convat_ws() function as the SJA does, because …
3) .. if no options is specified the comcat_ws() takes all columns as argument. With such long table definition you absolutely should use the option if possible – that is if you can specify a unique combinations of columns. Then only the specified columns will be used as argument with concat_ws(). Also the with the 'timestamp' column seems possible. It not defined as 'CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP' Is it a pretty old MySQL version, where this is not possible? However if you appliation does the same that would be the same.
Try to execute
SELECT concat_ws(all columns go as argument) on the source server (where data are) with any client:
Something like: SELECT concat_ws('_',`maillog`.`column1`,`maillog`.`column2` etc.) from tbl_a limit 100;
I do not think it hangs. I think it is working! And it cannot works faster than it gets the data it needs from the servers!
Check CPU and Network traffic from Task Manager! And don't be surprised if traffic is only 5-10 KB/sec. That is quite common with the sort of operation on cheap ISP's with a shared database server.
If you work with big databases you should learn to use the and -options effectively.
(be aware that it migrates your 'Personal' folder to a 'favorites' folder if you 'install over'. If you do not want that then just install to another folder).
The 'export' tool here has implemented an option to select/deselect 'drop trigger' statment. This seems to be forgotten in the 'backup' powertool. See attached pics. 'drop trigger' is written to the file if 'create trigger is' selected.
To use the 'include drop trigger' with the export tool:
If you restore to an empty database you must deselect it.
To restore into a database where that trigger exists you must select it.
And if situation changed in between you'll have to edit the file! As 'if exists' is not available we have to chance to 'automate' it.
This should answer what you can do!
2)
To understand why this happened we will need more information about the server!
What server version? Is current version installed over a previous version?
If yes did you run all update scripts as specifed in the MySQL documentation.
Now is the database from where you made the backup still available? If yes then what does:
SELECT * from information_schema.TRIGGERS;
or
SELECT * from information_schema.TRIGGERS where TRIGGER_NAME = 'InsertHAENowDate';
return?
The backup tool does not 'invent' triggers. There must (have) been some trace of it in the system!
3)
I also just reported a bug with backup of triggers here myself:
peterlaursen
Participant
