PlanetMysql.ru — информация о СУБД MySQL

Hello,

We are delighted to announce the release of SQLyog 10.0. The version number makes this release very special. We must say the journey from SQLyog 1.0 to 10.0 was very exciting and rewarding. SQLyog was first released in 2002 as a MySQL GUI. Now we are a decade away from the first release. During the course of time, we have introduced tons of features taking SQLyog beyond the definition of a GUI. We couldn’t have done it without your encouragement and patronage. A big thank you for being with us in this endeavour.

Listed below are the features and enhancements introduced in this release:

• Refreshing modern looks. We redesigned the user interface with a soothing color palette. We call it Twilight. You can also design your own themes and there is an option to switch to your default desktop theme as well.
• The data tab is now moved to the upper pane. With this, all important tabs are in the upper pane and you can see more of what you want to see, and more than one table data can be opened under the same connection.
• Schema synchronization logic is optimized and now it is up to 100 times faster for large schemas.
• Introduced many keyboard shortcuts for power users.
• Added an option for multi-column sorting and filtering of table data.
• Many more usability enhancements and bug fixes.

Please refer to the version history for detailed release notes.

SQLyog customers can download SQLyog 10.0 GA from the Customer Area. Please make sure to get the new registration keys for SQLyog 10.0 from the Customer Area.

To evaluate SQLyog 10.0 GA please download a 30-day Trial.

We are very excited about this release, and hope that you will like it. We would love to hear from you!

Cheers,
Team SQLyog

Changes (as compared to 9.61) include:

Features:
* A Korean translation is now included.

Miscellaneous:
* The localization tools have been updated. The compiler for building localizations is now up to 100 times faster than before. Also the XML has now been properly versioned. Refer this blog on how to download the localization kit.

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

Changes (as compared to 9.61) include:

Features:
* A Korean translation is now included.

Miscellaneous:
* The localization tools have been updated. The compiler for building localizations is now up to 100 times faster than before. Also the XML has now been properly versioned. Refer this blog on how to download the localization kit.

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

Changes (as compared to 9.6) include:

Features:
* A Chinese (Simplified) translation is now included.

Bug fixes:
* When there was an INFO tab open the server was unnessarily queried for the content of the INFO tab (based on Object Browser selection) when closing the program. This could cause a slow shutdown.
* Fixed a crash occurring when pressing the ESC key in the CREATE/ALTER tab/dialog. This bug was introduced in 9.6.

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

Changes (as compared to 9.51) include:

Features:
* When performing CREATE/ALTER TABLE operation from inside the Schema Designer now a dialog with a tabbed interface similar to the CREATE/ALTER TABLE tab will open.
* It is now optional if Query Builder will create statements with ‘fully qualified tablenames’ or not.
* Implemented Alt+Ins, Alt+Del, Alt+Up and Alt+Down for inserting, deleting, moving up/down the rows in CREATE|ALTER TABLE interface when the focus is on respective grids. The tooltip for the toolbar buttons will now show this shortcuts.

Bug fixes:
* In Data Sync a low setting of ’max_allowed_packet’ on source server could result in CONCAT_WS() used for checksums’ calculation returning NULL . We did not consider this and as a consequence rows could fail to sync without warning. We will now abort the job with an error message (if user has selected to ‘abort on error’) or print an error to the sja.log file and the console (if user has selected not to ‘abort on error’ ) informing that some rows may have been skippped in such cases.
* The fix for empty string defaults in 9.51 was not complete. It was (unlike 9.5) possible to create such default but it did not display as ” after creation in ALTER TABLE.
* If multiple databases with same name existed only differing in lettercase SQLyog would generate certain statements using the ‘mostly lowercased’ database name. This bug was introduced in 9.5.
* Autocomplete runs in a separate connection, but also when Autocomplete was disabled this connection was created for no reason.
* SQLyog sometimes waited unnecessarily long (30 seconds – what is the client timeout setting we use internally) to report that SSH connection could not be established. This happened for instance if a wrong RSA passphrase was entered. In such and other cases there is no reason to wait for client timeout.
* Small fixes – mostly GUI fixes to the new CREATE/ALTER TABLE interface.

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

Baron Schwartz from Percona has  just re-invented the SQLyog Query Profiler.
Refer: http://www.mysqlperformanceblog.com/2012/02/20/how-to-convert-show-profiles-into-a-real-profile/

The SQLyog Query Profiler was introduced in SQLyog 8.o in February 2009 – exactly 3 years ago. The funny thing is actually that Baron Schwartz reviewed it before release (at friendly commercial terms) at the time. The SUM-aggregation and the ORDERING that we did (and it was solely our decision – not Baron’s advice) in SQLyog 8.0 to the result from SELECT FROM I_S.PROFILES is the same as Baron now announces as “something I developed”.

Well ..

1) First let me make it clear that I am not complaing.  I believe Baron when he tells that he does not remember details of the SQLyog Query Profiler today. When I use the term funny above I mean it. Baron is welcome to re-use it even if he forgot and had to re-invent it (and also we re-use his ‘Change Of STATUS VARIABLES Due To Execution Of Query’ profiling concept from the original Maatkit release as well).

2) But *developed* is a pretty strong term to use for a rather trivial query (just a SELECT .. SUM() ..  GROUP BY .. ORDER BY .. basically), I think.  Just like there are only 12 note in (western) music and it is difficult to write music that does not resemble previous music somehow, it is also difficult to write queries that do not resemble previous queries (I know chess-players would disagree – with 64 squares and 32 pieces  possibilities seem infinite – but maybe the rules of chess allow for more creative combinations than the rules of SQL? I belive so.  It probably also applies to music – but not to SQL IMHO ).

Happy PROFILING! And Chess-playing!

Hello!

We are delighted to announce the release of SQLyog 9.5 GA. This release is geared towards enhancing the user experience.

The major changes are:

• The conversion of modal dialogue boxes to a tabbed interface for creating and altering tables, and defining table properties.
  • Creating a table involves – defining columns, and often, creating indexes and foreign keys. Before, these actions had to be done one after the other, which was annoyingly slow. Now, you can define columns, and create indexes and foreign keys – all in a single interface, which gives you a single CREATE/ALTER TABLE query to execute. Not only is creating tables easier, it is also much faster!
  • Modal dialogue boxes limit one from multitasking. Previously, when in the middle of creating a foreign key, if some information had to be looked up from a different table (or even the same table), it required one to close all the dialogue boxes, get the information, and then start again from scratch! Now, while working on creating a table, you can go to another tab, check for some details and return back to creating the table.
• History and Info tabs now appear alongside the Query tab. As the content of these two tabs is not dependent on a specific Query tab, it is logical to not have these under the Query tab. Additionally, these tabs consume one third of the system resource that they did before.
• Content of History and Info tabs is now searchable.

The all new create table interface

Refer the following posts for detailed release notes:

• SQLyog 9.5 Beta 2 Released
• SQLyog 9.5 Beta 1 Released

SQLyog customers can download SQLyog 9.5 GA from the Customer Area.

To evaluate SQLyog 9.5 GA please download a 30-day Trial.

We are very excited about this release, and hope that you will like it. We would love to hear from you!

Cheers,
Team SQLyog

The headline above has two parts: 1) some letters 2) a question mark. The question mark is the important thing here! It resolves to:

* Can we debug stored programs in MySQL?
* Do you debug stored programs in MySQL?
* How do you debug stored programs in MySQL?

We have tried, but we gave up! In the early stages of our IssueBurner application we actually used Stored Procedures quite a lot. As the complexity increased debugging became so tedious that we recoded the application ‘the traditional way’ coding the logic in the application code instead.

In simple cases you may of course add a little debugging code that writes some data to user variables, temporary tables etc. Next remove them or comment them when you want to turn debugging off. If you want to work more systematically you can add a IN-parameter (debug: integer) to a Stored Procedure paramer-list and CALL mysp(….,0|1) what would then control if the stored program should enter or bypass debugging code when executing.

It should not be like that in the 21st century. Debugging options should be part of the server code itself and there should be an API for it. You should be able to execute line-by-line, set breakpoints, view the status of variables, handles and cursors for every step  just like you would do in a true Integrated Development Environment (IDE). Stored programs is code just like application code is.

Some years ago (I think around 3 years ago) I joined a ‘vote’ on the MySQL website where I had an option to vote for my personal priorities of future MySQL development. An API for debugging stored programs was one of the options listed and I cast all my 10 votes to it.

I would not live without Stored Functions and Events. They will also most often be pretty simple and thus rarely cause problems. Stored Programs is another matter – they can be and will often need to be very complex to be usable for what you want to achieve (and let us forget Triggers here – they are close to being a joke in MySQL).

I have seen some solutions claiming to be able to debug MySQL Stored Procedures. What I have seen all use some kind of (very simple, really) emulation (like replacing loops with sequential statements, local variables with user variables or they will rewrite the original SP to a ‘cascaded series’ of SP’s calling each others). All what I have seen fails with examples just a little bit more complex than trivial (a few nested loops, some handlers or cursors and similar is usually enough to get weird results).

I write this because we now again had a request for a ‘stored program debugger’ in SQLyog. We would be happy to develop it (it is around 5 years ago we discussed first time I think), but without proper API support from the server we will not even attempt it. Past attempts are not encouraging.

I wonder:
* Does anybody know about any progress with stored programs debugging API/functionalities in MySQL?
* How do you debug your stored programs?

As we announced in the release Blog for SQLyog version 9.3 we here publish instructions and tools for localizing SQLyog.

To understand how localization works you should first open the SQLyog 9.3 installation folder on your system. Inside it there is a (SQLite) database file named “L10n.db”. It contains all strings in all localizations distributed by us (currently English and Japanese) displayed by SQLyog GUI. If you have selected to run SQLyg in a non-English language SQLyog will load the localized strings from this file and use them for display and not the English strings.  To enable more languages just copy an updated “L10n.db” file with support for more languages into the SQLyog installation folder.

The tools for localization are available from the SQLyog Community repository at Googlecode (http://code.google.com/p/sqlyog/). To check out use the link https://sqlyog.googlecode.com/svn/trunk/localization/ for your SVN client (TortoiseSVN recommended for most Windows users). From here on we will use the term SQLyog localization kit for the contents of this ../localization/ folder. It contains tools needed to add more languages/localizations to the “L10n.db” file.

Let us start listing the content:

* In the ‘bin’ folder you will find a “L10n.db” database completely identical to the one shipped with the SQLyog installer.

* In the ‘Strings’ folder you will find a XML-file named “Config.XML” and (in a recursive “String” folder) a folder for each language supported (named “en” and “ja”). In each of those folders you will find a number of XML files (following ‘Android XML’ specification) with English and localized Japanese strings respectively.

* The batch file ‘compile.bat’.  It is a batch script calling a ‘compiler’ that generates an updated “L10n.db file” based on the content of the “Strings” folder.

* The ‘Tools’ folder is not something you should normally care about. It contains some resources, shared libraries and executables etc. (such as the ‘compiler’ referred to above).  The content of it is used by the ‘compile.bat’ file – and not by user/translator directly.  

To make a translation there are bascially 4 steps:

1)

First step is to define a new language in the “Config.XML” file. We will assume that we are translating to German. In the passage that looks like

<language>
<ja langname=”日本語” />
</language>

.. add support for German like this:

<language>
<ja langname=”日本語” />
<de langname=”Deutsch” />
</language>

“de” is the language code and “Deutsch” is how it will display in the SQLyog UI. Please note that we use the language codes from this Microsoft document. It does not matter currently actually, but it may later be used for auto-detection of some LOCALE-specific parameters (decimal format, date format etc.), so please stick to the Microsoft recommendation unless there is a compelling reason not to do so. Also be careful not to change the encoding of the file. It is UTF8 and should remain so.

2)

Make a copy of the “en” folder and rename the copy “de”.

3)

Now comes the hard work. Translate the XML files in the “de” folder from English to German. And again be careful not to change the encoding of the files.

Also note the details:

* XML standards for encoding of special characters must be honoured (‘&apos;’ for “‘” (apostrophe) etc.)

* occurrences of “%d” and “%s” must be kept as they are and should be in the same order they appear in “en”. Failure to do so will result in an error in the next step.

* Also keyboard shortcuts are handled from the XML files. Actually there are two kinds of keyboard shortcuts in SQLyog (like in most Windows programs):

a) One kind is ‘static shortcuts’.

Those are the ones the you find listed in the “help .. keyboard shortcuts’ menu. Let’s have a look at a randomly picked string in English here:

<string name=”1027″>Schema Synchronization Tool (Ctrl+Q)</string>

The substring “(Ctrl+Q)” should not be translated. This kind of keyboard shortcuts are not localized. “(Ctrl+Q)” is just part of what is displayed. It is a constant string. The functionality of this type of shortcut is hardcoded into SQLyog.

b) ‘language dependent shortcuts’.

This is a Windows feature that it seems a lot of people don’t really know about. To understand what it is (if you don’t) just open SQLyog (in English) and press the ALT key. You will see that some letters in the menu become underlined.  For instance in the menu item “Table”, the “a” is underlined. You may next open the table menu by pressing “a” and even continue selecting from the submenu pressing a single letter key. In Windows this is achieved by preceeding “a” with an “&” in the menu (where it is not displayed – it only ‘codes’ the “a” to be a shortcut). So Windows ‘knows’ this menu item as “T&able” internally. That string is also what the “L10n.db” database contains.  Do not forget here that in the XML files “&” needs to be encoded as “&amp;”. So the German string in the XML file for the “Table” menu item could be “T&amp;abelle” (if you want to keep “a” as the ALT-keyboard shortcut in German). When choosing this type of shortcuts you should be careful not to use the same more than once in same menu level and you should of course try to follow de-facto standards as used in localized Windows itself, utilities that ship with Windows (Notepad etc.) as well as commonly used Windows programs (like office suites, browsers etc.).

Also you may use XML/HTML-comments in the XML-files.  That could be useful for instance if more people share the work of a translation or if there is something that you want to identify easily later.

A concluding comment on editors: Some editors may have issues with UTF8 and they should not be used. Notepad will work fine but it does not support syntax highlighting, auto-indenting and similar ‘developer features’ that are convenient to have. We have checked with Notepad++ that works fine – but there are undoubtedly dozens of editors available out there that will do the job. And also do not use a Word Processor – it should be a plain text editor.

4)

Once you have completed the translation of the XML files just execute the ‘compile.bat’ file from command line. German strings from the XML files you translated will be inserted to the ‘L10n.db’ database in the ‘bin’ folder. The updated ‘L10n.db’ can now be copied into the SQLyog installation folder and SQLyog will have the option for German language.  

Finally please note that we have a category in our Forums dedicated to localization.  If you are facing a problem feel free to discuss with us or fellow countrymen for details of a translation.

“Publishing software in English will make you reach most of the global audience” is a myth. Users like software in their own language. For Non-English speaking audience localized software is a necessity. We heard it. SQLyog is now available in Japanese & will be made available in other international languages soon. We are using crowd-sourced human translation services from myGengo for translating SQLyog. I’d also like to add that our website is machine translated using Google Translate.

Embedded below are some related screenshots:

Option to change language

SQLyog in Japanese

If you want to do your own translation, we will soon provide instructions and tools for creating localizations as a ‘drop-in’ solution to an already installed instance. Watch this space for a post on it.

We are very excited about this release would love to have your feedback. What other languages would you like SQLyog in?

Regards,
Chirag
Team SQLyog