Changes (as compared to 8.13 beta 1) include:
* When updating from DATA or RESULT grid the UPDATE statement will now only list columns that were changed. That results in more readable statements and may also improve performance with ‘wide’ tables and tables with large BLOB/TEXT columns.
* As a consequence of the above the restriction, that a grid containing spatial or binary data could not be updated, has been lifted (but such columns themselves still cannot be updated from the grid).
* Added an option to perform backups in a single transaction (similar to ‘mysqldump’ “–single-transaction” option).
* The connection manager has been redesigned to allow for longer connection names. Also the ‘…’ button was renamed to ‘rename’ (what was what it always did).
* Added support for MySQL compressed protocol in both SQLyog GUI and SJA. Please see detailed note below.
* Added an option for user to specify the timeout setting for the session (note: it will work with MySQL 5.0 and up only as earlier versions do not support SESSION variables). Please see detailed note below.
* Now SQLyog logs to the sqlyog.err file if memory allocation fails with string manipulation (for example when handling blob/text data where a single value may be larger than available memory).
* Version parameter was added to SJA. You can now execute “sja –version” or “sja -v” and version will be returned. Before only the file size could be used to detect the SJA version.
* Now full GUI support for all charsets added to MySQL after 5.1. Everwhere SQLyog presents user for a list of available charsets and collations the server will be queried about this information. Before it was not like that everywhere!
* If the custom size for bulk insert in ‘preferences’ is greater than server default, then SQLyog will use the server default for generating BULK INSERT statements. Users overlooked/forgot that they had specified a setting. As a result backups that would not restore on same server could occur. Also now user specification is restricted to 5 digits (what means it will have to be less than 100 MB).
* The various options available for backups have been reorganised in GUI to make it more clear what options have effect on the source server while backup job is running and what options are options that are written to the file.
* A new query tab can now be opened by double-clicking in the unused space to the right of existing open tabs.
* SQLyog could fail to save properly from RESULT tab if PK-column(s) were not displayed in GRID (an incorrect WHERE-clause was generated). This bug was introduced in 8.1.
* Data Sync could throw an incorrect ‘AUTO INCREMENT definition mismatch’ error for data types (like TIMESTAMP type) where auto-increment does not apply with specific schemas. Also this bug affected Schema Sync.
* Fixed a crash in Scheduled Backup.
* A scheduled SJA job raised an internal error code in the Windows scheduler. It had no effect on the job as such (queries were executed, mails were sent), but various monitoring tools for Windows servers would raise an alert.
* Emptying a database rendered Autocomplete non-functional for the session.
* Fixed an issue with Schema Sync if the same ‘stored program’ was formatted differently on source and target. Target was not always synced properly and SS would detect differences forever.
* On Wine Data Sync could pop up a message that SJA had crashed. But actually it only crashed after user clicked OK in the dialogue.
* SQLyog reconnects are now coded differently. The new code means that with SSH-tunnel it will now not be necessary to re-instantiate PLINK (the running PLINK instance will be used).
* DO NOT take for granted that use of compressed protocol will always increase performance, because the truth is that most often it will make things slower. Use of compressed protocol will decrease the amount of data to be transferrred over the network, but it will result in additional load on both the server and the client (due to compressing and uncompressing). You should never use the option when connecting to MySQL on local machine, on local network or over a fast Internet connection. With slower connections however using this option may improve overall performance. It is impossible to be more specific as most Internet connections have asymmetric properties that differ across Internet providers and telecom companies.
* The option to define timeout for the session (different from the global setting) is possible with MySQL servers from 5.0 and up. However most users will not need to care about it – not even if server (global) timeout setting is low. SQLyog will reconnect if connection was lost since last query was run. Most often user does not even notice. However we have reports of situations where the network takes very long time to process such reconnect requests. In this situation setting the timeout from the client will prevent the situation to occur. Also SSH-users connecting to SSH servers/daemons that are slow to establish connection and where MySQL has a low timeout setting can use this option with advantage.