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

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

We have released SQLyog 9.2 GA with enhancements to the Data Search feature (and more).

Since we introduced the Data Search feature in SQLyog 9.1 we had a lot of positive responses – but also a few critical remarks that using the feature could cause unnecessary server load as well as unnecessarily long response times. Such scenario could arise when searching for a string in a BLOB column used for storing media files for instance. Or when searching all tables of a database when there was only need to search a few tables.

We have addressed this concern by adding filter options that let the user restrict the search to specific data types and to a subset of databases of a server, a subset of tables of a database or a subset of columns of a table.

Also we have added “+” and “-” operators for inclusive and exclusive exact match.

I would like to elaborate a little more on Data Search:

Data Search does not replace SQL, of course. It is a supplementing feature. It is in particular useful when your are searching for something you don’t know what exactly is and don’t know exactly where to find. And when you are just too lazy to write a long SQL statement. As we have posted here before you could consider the Data Search feature as a tool to ‘google your database’ (as google ‘advanced search’ operators are used). But a database has a hierachy and has datatypes what a document has not. So this filtering option is a logical database-related enhancement to the google ‘advanced search’ syntax used for documents.

Let us take an example: Suppose you want to find all instances of email addresses with a specific domain name in all your networked systems (on the Internet as well as Intranet). We have 3 such public systems (our Forums, Blog and FAQ) for our MySQL-related products alone  that are ‘standard applications’ that we did not code ourselves and thus do not know internals about very well. In all those systems people may comment or contact us. Add to this our non-public systems – like our CRM system and our support ticket system (based on our own web application IssueBurner that aggregates everything sent from and received to our contact email addresses to a database). As all the mentioned systems use a MySQL backend we will now easily be able to answer the question “Who have ever contacted us with a @like.this email address, when did it happen and what was the subject/matter?”. Simply because we can find the data in all systems. And anybody in our organization can do (provided that they have access) without knowing details about how and where the different applications store the information.

When we introduced Data Search in 9.1 I actually expected some comments that “this is a feature for amateurs and I do not intend to use it as I am familiar with SQL”. We did not get such comments till now! I think users already found out that it saves a lot of time.

Also in this release we are following up on the ‘Foreign Key lookup’ introduced in 9.0. This is now also functional from the RESULT tab in SQLyog.

And finally In this realease we added a ‘date picker’ GUI for managing DATE, DATETIME and TIMESTAMP columns as well as an option to clone a connection. Both were popular user requests for some time and have now been implemented.

See all details for this and other recent releases here.

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

We are pleased to announce this new major release of SQLyog MySQL GUI.

The major enhancements with this release are:

* Information in tabbed interface can be reordered.
Just like you will find it in all modern browsers, TABs can now be reordered using drag’n’drop in the GUI. The option is available for connection tabs as well as Query/Query Builder/Schema Designer tabs.

* Fast and convenient data entry from the keyboard.
We have added ‘FORM view’ option (in addition to ‘GRID view’ and ‘TEXT view’ already available) for managing data in DATA and RESULT tabs. ‘FORM view’ will display one row at a time and is in particular convenient when entering data from the keyboard.

* Query Formatter
The SQLyog Query Formatter is now completely rewritten. In principle all types of SQL statements are now supported and all limitations with the old implementation are lifted.

* Several editor enhancements including:
The Editor now has a ‘folding option’. Multi-line code and comment blocks between bracket-pairs, BEGIN-END pairs, C-style comment pairs (/* and */), WHILE-END WHILE pairs, LOOP-END LOOP pairs, REPEAT-END REPEAT pairs and CASE-END CASE pairs can now be ‘folded’ in/out (ie: hidden or unhidden).

Add to that numerous stability fixes, GUI improvements and more. Read full details here.

We hope you will like this new version – and do not hesitate to contact us if you have comments, suggestions or whatever.

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

We are pleased to announce the release of SQLyog – MySQL GUI 8.6 GA. This release adds functionalities requested by users for some time, and fixes a number of bugs. Most important enhancements:

User management has been updated with a brand-new interface, has been completely rewritten and also now fully communicates with the MySQL server the recommended way using GRANT and REVOKE syntax. We believe that with this release we have provided the best available ever GUI for MySQL User Management.

For users that prefer to work in a spreadsheet-like interface when filtering and sorting data the options to do this have been enhanced: There is now a ‘custom filter’ option to be used when filtering on a value that does not exist in the result set displayed – or even is not stored in the table at all. Additionally you may now define the substring to be filtered on in more flexible ways than before.

In the editor we added “parenthesis’es matching”. With complex statements (JOINs on derived tables, SUBQUERIES, statements with nested functions and similar) this will make it much easier to identify the structure of the statement. Just position the cursor after a parenthesis and the actual parenthesis and its match will highlight.

We have improved performance by optimizing code in code segments executed most frequently. Additionally we have deployed more debugging and performance measuring tools. This includes – but is not restricted to – moving our build environment to latest Visual Studio environment (2010 edition).

Note that with this release we have stopped supporting Windows 2000. It has for some time been increasingly difficult to continue this support. It is actually quite hard to find a recent system where Windows 2000 will run without errors and we have over the few last years spent quite a lot of effort fixing issues occurring only on this variant of Windows. We believe that the effort is better used ensuring optimal performance on recent and still supported Windows variants – not at least Windows 7, what fastly is taking the position of the dominating Windows variant. The move to Visual Studio 2010 shall be seen in this context. But of course XP, Vista (and the same generations of Windows server variants: 2003 and 2008) are still supported as well as Wine.

Links to Beta/RC release blogs with detailed information.
* http://www.webyog.com/blog/2010/08/17/sqlyog-mysql-gui-8-6-rc3-released/
* http://www.webyog.com/blog/2010/08/06/sqlyog-mysql-gui-8-6-rc2-released/
* http://www.webyog.com/blog/2010/08/06/sqlyog-mysql-gui-8-6-rc-released/
* http://www.webyog.com/blog/2010/08/03/sqlyog-mysql-gui-8-6-beta3-released/
* http://www.webyog.com/blog/2010/07/22/sqlyog-mysql-gui-8-6-beta2-released/
* http://www.webyog.com/blog/2010/07/20/sqlyog-mysql-gui-8-6-beta1-released/

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

Hi,

We are pleased to announce the release of SQLyog – MySQL GUI 8.5 GA. Below are some pointers:

• As the title suggests this release comes with tabbed interface for different connections. We need not have to emphasize the usability of a tabbed interface vs. a windowed one. All web browsers have already demonstrated it to us. Now in SQLyog, you can switch between different connections in a snap! We didn’t forget to add keyboard shortcuts to jump from one tab to other. Most – if not all – shortcuts for tabs of a standard web browser would work with SQLyog. Multi-coloring of connection tabs & object browser pane adds to the ease of use. Chances of one executing queries in one server than the other by mistake would be rare as the brain would easily grasp the connection by it’s color. Demoed below is a typical setup of multi-colored tabs in a Web Developer’s PC:

• If you remember we added client side sorting of Result set data in SQLyog 8.4. With this release you can even filter the data of Result set on client side unlike Table Data where a query is fired to server for every sort or filter action. One more addition to view relevant data quickly.
• Who likes to right-click & open a file when you can just drag-and-drop? We bet you don’t. You can drag-and-drop files (SQL or Schema Design XML/Query Builder XML) directly into SQLyog.
• Whoever uses SQLyog for data entry or manipulation would love this feature to duplicate data in a record. Many a time all one needs is to change only few fields & retain the rest of the data from the preceding row. This feature would come handy in such cases. Tables with auto_increment columns are handed automatically.

This release also contains many more enhancements & bug fixes. Refer the following release notes for details:

• SQLyog 8.5 RC3 Release Notes
• SQLyog 8.5 RC2 Release Notes
• SQLyog 8.5 RC Release Notes
• SQLyog 8.5 beta3 Release Notes
• SQLyog 8.5 beta2 Release Notes
• SQLyog 8.5 beta1 Release Notes

SQLyog customers can download the latest installer from Webyog’s Customer Portal.
To evaluate SQLyog, please download the 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

Hi,

SQLyog 8.4 happens to be a fairly major release with good number of features & enhancements. Listed below are some worth noting.

• May it be Query Profiler or Datatype Optimizer, SQLyog has grown beyond the definition of a GUI with these features with intelligence. One such feature that is being unveiled with this release is an option to find redundant indexes. You can find the redundant indexes in a Table with just a click of a button. If found, a ready query is generated to drop the redundant indexes. As you know eliminating redundant indexes improves INSERTs & UPDATEs and also saves hard-disk space.
• Scheduled Backups can be compressed.
• If you are one of those users who deal with databases having thousands of objects (tables, columns etc.) this release will definitely add to your productivity as auto-complete has been drastically improved for such databases.
• You can sort the data of Result set. The sorting is very fast as it is done at the client side unlike Table Data where a query is fired to server for every sort action.

Redundant Index Finder

This release also contains following enhancements:

• A file can be loaded to the tab from context menu.
• Added menu items (for exports and ‘copy to other..’) at table-level in Object Browser.
• Save dialog when closing a connection now has ’Yes to All’ and ‘No to All’ options.
• Added an option to send a mail alert if an error occurs while executing a ‘maintenance query’ from Notifications Services.

SQLyog customers can download the latest installer from Webyog’s Customer Portal.
To evaluate SQLyog, please download the 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

PS: Redundant Index Finder is a feature of SQLyog Ultimate only.

Changes (as compared to 8.22) include:

Features:
* Added an option to define a ‘color code’ for a connection. The color will be used as background color in the Object Browser.
* A Query Builder session can now be saved and resumed.
* In Query Builder a table alias can be defined for any table by double-clicking the title bar of the table symbol.
* In RESULT tab results can now be retrieved page-wise. This is ON as default with this build with a defined LIMIT of 1000 rows. For a specific query user can change and for this specific query the setting is persistent across sessions. Also read ‘miscellaneous’ paragraph below.
* Added a context menu to Query Builder canvas.

Bug Fixes:
* Deleting a user would leave non-global privileges orphaned in the ‘mysql’ database. Now we use DELETE USER syntax if server supports.
* Also using EDIT USER dialogue to change host or user specifier for a user would not move non-global privileges. We have split the old ALTER USER dialogue into two: a EDIT USER and RENAME USER dialogue. The latter will use RENAME USER syntax if server supports.
* On Wine Data Sync could generate a malformed XML-string what would case Data Sync to abort.
* Fixed an issue where SSH-tunneling failed with public/private key authentication. Technically the fix is in the PLINK binary shipped with SQLyog.
* SJA failed to send notification mails if Yahoo SMTP servers were used. Note that the fix disables encryption option with Yahoo SMTP servers – but it won’t work anyway due to a non-standard SMTP implementation server-side.
* When importing data from a Universe ODBC-source string data could be truncated.
* The fix in 8.22 for the issue that horizontal scrollbar in GRID would sometime not appear was not complete. It could still happen.
* SQLyog will now trim trailing whitespaces in Connection Manager and Create object dialogs to avoid MySQL Errors..
* Opening a file from ‘recent files’ list could crash SQLyog if a Query Builder or Schema Designer tab was selected and the file specified was not a valid XML file for that tab. This bug was introduced in beta 1.
* When calling a Stored Procedure with more than one SELECT statement from ‘Notifications Services’ only one result set was sent by mail.
* The sja.log file had no line-breaks between what was recorded for two jobs.
* On multi-monitor system resizable dialogues could open on the wrong monitor. New implementation is like this: on multi-monitor systems main program dialogue and ‘first child dialogue’ (example: ALTER TABLE) will open where they were closed (if possible), second and higher child dialogues (example: table advanced properties) will always open on top of its ‘parent’ dialogue. Non-resizable dialogues (such as confirmation boxes) will always open on top of their ‘parent’.
* With multiple SSH-tunnelled connections open stopping and re-executing queries in multiple connections in a fast manner could crash SQLyog.
* If more than one comment occurred before a SELECT statement in the editor, the statement was not identified as a SELECT statement by the Query Profiler and the Query Profiler TAB would not display.
* We did not validate client-side if user checked atoincrement option for a bit column with Create/Alter table dialog.
* If an error occurred while renaming a trigger then trigger was lost as SQLyog was not recreating it back.
* Small GUI fixes.

Miscellaneous:
* The default LIMIT setting for DATA tab has been removed. The setting is not required since we introduced table-level persistence for number of rows displayed. The default for new tables that have not been opened before is 50 – but when user changes the value and next ‘refresh’es SQLyog will save the LIMIT for that particular table persistently across sessions. This in combination with page-wise display in RESULT tab results in a more uniform User Interface for DATA and RESULT tabs.

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