Changes (as compared to 8.21) include:

Bug Fixes:
* ‘Test connection’ would succeed even if a non-existing database was specified in the database field. Connection would next fail.
* Database name (if any) would erase on clicking OK in error dialog in connection window.
* HTML exports could drop the first character of string output.
* With multimonitor setup and SQLyog on the right screen some rarely used dialogues would pop up on left screen.
* Copy database/table will now display ‘connecting to source/target server’ while connecting.  If establishing connection took more than a few seconds users could have the impression that nothing was happening.
* An extra RESULT tab could appear when executing a query.  This bug was introduced in 8.2. Professional and Enterprise editions were affected.
* In notification wizard sending mail would fail if there was no semicolon after the query and “include original query” option was checked.
* With more than 65 536 (2^16) rows displayed in GRID, the GRID scrollbar would expose strange behavior. We were using a scroll control using 16 bit integers internally.  New scroll control handles +4 billion rows.
* In Wine when displaying very wide tables and result sets (like 500+ columns) the column header could disappear. The underlying reason was that Wine failed to render a gradient as transparent but rendered it as opaque instead.
* Horizontal scrollbar in GRID would sometime not appear when executing a query returning a large number of columns if not scrollbar was required for previous query.
* With larger than ‘normal’ DPI setting the BLOB Viewer header would not display properly.
* ‘Export as SQL-dump’ dialogue was redesigned to allow for longer files paths.

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

Comments(4)

This release has (as compared to beta 1) no technical changes that should affect users.  Changes between the beta and this one are internal only – like code refactoring/cleanup, some very small GUI fixes etc.

However note that the full-featured “MONyog” (as you know it) was was renamed to “MONyog Ultimate”.  Full details will be available with the upcoming GA release. A new licensing scheme is planned from 3.7 GA. But note: this will not affect existing users.

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

Comments(0)

Changes (as compared to 3.65) include:

Features:
* The MONyog ‘admin’ user can now create other users having access to a subset of available servers only.  For those non-admin users access to edit server settings, to KILL queries and to execute  FLUSH STATUS is optional. Also note that only ‘admin’ is allowed to create/delete server and user registrations.
* Monitors/advisors page can now be exported as CSV.
* Some counters in Monitors/advisors page were rearranged. Details about this:

• “Security” and “Excessive Privileges” groups have been moved to the top.
• “Table Cache” and “Table Locks” have been merged to a single group “Table Cache & Locks”
• “Thread Cache” and “Slow Launch Threads” have been combined to a single group named “Threads”
• “Commands” and “Schema Changes” have been merged to a single group “Commands & Schema Changes”
• Counters in “Network Traffic” has been moved to “Connection History”
• Counters in “Sort Buffers” has been moved to “Misc.”

Bug Fixes:
* FLUSH STATUS was not working for servers having space(s) in their names.
* Warning also displayed when global notifications are disabled.
* Duplicate ‘Server restarted’ messages were sometimes sent when MONyog is restarted.

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

Comments(1)

Hi,

We are pleased to introduce our new product MailBrowser – a free Gmail Plugin that helps you easily manage your contacts and attachments. A 5-minute demo video is embedded below.

Read MailBrowser reviews at ReadWriteWeb, Scobleizer & Lifehacker. It should be a great addon for all Gmail and Google Apps users. Please give it a try & let us know your feedback at feedback@mailbrowser.com.

And, now comes the announcement of Amazon Kindle Winners. Thanks everyone for participating.

The most original and feature-specific tweets winning Kindles are:

1. http://twitter.com/gstrohm/status/6671741181
2. http://twitter.com/raylance/status/6661029609

Congratulations to Gary & Ray. Please DM your email address to @webyog so that we can collect your details to ship Kindles.

Keep following @webyog on Twitter for news, contests, discount offers on Webyog products.

Regards,
Team Webyog

Comments(0)

Changes (as compared to 8.2) include:

Features:
* Now SJA will also send mail alert if job aborted due to MySQL error. Before it was only internal SJA error.
* The local port used by SSH-tunneling will now be selected automatically. This will avoid conflicts in case multiple programs use SSH. Also with Data Sync from command-line/scheduler it was possible to use same port for both connections what would effectively sync a server with itself.
* Caption for ‘Parse’ button in Notification Services Wizard was changed to make it clear that it will actually execute the statement(s) entered. There is no way to let the server parse a statement except for executing it.
* Connection windows for SSH connections will now list SSH host details in the title bar.
* Tooltips for an icon will now list the keyboard shortcut performing same action.
* The option to display ‘all’ versus a ‘LIMIT’ed set of rows in DATA tab is now table-specific and saved across sessions (note that – similar to the ‘column width persistence’ feature – connection parameters are not using for identifying a table; only the database name and the table name are).
* Objects in an Object Browser node is now sorted case-insensitive.

Bug Fixes:
* Continuously clicking the ‘Calculate’ button in Schema Optimizer in a fast manner could crash SQLyog.
* The keyword.db file (used by auto-complete and syntax highlighting) is now read only. Various validators for Windows7-compatibility would report that SQLyog wrote to “Program Files” folder at runtime (what it did not).
* When copying to clipboard an out of memory error could occur also when there was enough memory.
* The table menu will now indicate what storage engine is currently used for the table.
* Autocomplete and syntax highlighting did not recognize keywords archive, blackhole, federated, example, maria, pbxt, federatedx, falcon and mrg_myisam.
* Notifications Services/’Send Query to Email address’ option did not send a mail if an error occurred. Now a mail listing the error will be sent.
* We did not validate client-side if user specified a default value for an auto-increment column (what is invalid with MySQL).
* In DATA and RESULT tab the context menu was only working from GRID-cells. Now it also does from GRID headers and ‘whitespace’ in the tabs.
* Updating a ’TIMESTAMP on update CURRENT_TIMESTAMP’ had no effect (the particular column was not listed in the UPDATE-statement sent by SQLyog). This was a necessary restriction before 8.13 but since we – from 8.13 – only list columns that have actually been edited by user, we can now lift this restriction.
* Import External Data – TRIGGERS could fail to update a SQL Server (n)varchar if it contained an empty string.
* If user had selected to save SSH-password locally and later changed the password, the new password was not saved – unless clicking ’save’ button in connection manager interface.
* When importing an external script with no explicit SET NAMES on top, SET NAMES latin1 was executed by SQLyog. Now we won’t do this – and server default charset will have effect for the import in such case.
* Autocomplete did not handle identifiers with the ‘_’ character correctly what could result in too many matches when matching the database with a pattern in editor containing such character.
* Other small GUI fixes.

Miscellaneous:
* This release ships with an updated tunneler file for HTTP-tunneling. In the old tunneler file functions were used that are depreciated in PHP 5.3x.
* The ‘Objects’ menu was renamed to ‘Others’.

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

Comments(0)

Happy new year!

Just before Christmas the number of downloads of MONyog (from distinct email addresses) crossed 100,000. Here is the situation as of now:

This is of course a nice Christmas present for us to have. But more important: it reflects that today – as opposite to the situation just a few years ago – that even average MySQL users have understood that tuning the server configuration as well as the schemas and the queries used by applications is essential.

The default settings for the MySQL server are not appropriate for a heavy-loaded server and even the standard configuration files (or configuration ‘templates’) shipped with the server will not have the specific settings required for optimal configuration in most situations. And even the best server configuration won’t help much if databases and queries are poorly designed. We benefit from the growing understanding of this but also believe we have contributed significantly to it by making MONyog available. Its agentless design and the total lack of dependencies on external programs (database, web server, scripting environments) makes MONyog the easiest deploy-able solution for MySQL monitoring. You are up and running in less than 5 minutes. Additionally it is a very rich application providing functionalities you do not find anywhere in any other integrated solution.

Recent additions to MONyog include (just mentioning the most important things added in last few weeks before Christmas):

• Exports of Query Analyzer output for import to spreadsheets and databases for further analysis.
• Extended alerting options: now alerts can be send as mails or SNMP traps (or both) and alerts can be sent for long-running queries as you define it.
• The MONyog API: An HTTP-based (and thus totally cross-platform) interface for controlling MONyog from shells as well as scripting and programming environments. Introduced in 3.65 just before Christmas, it is far from complete as of now, but it is extensible – and will be extended.

And MONyog development does not stop here. We develop it aggressively and have recently increased the MONyog developer team. Stay tuned!

Regards,
Team MONyog

Comments(4)

Times are a-changing, and the past couple of months have witnessed a flurry of activity on the cloud computing front; namely, SQL Azure and Amazon RDS. Touted as the harbingers of a new era — the era of Relational DBMS-as-a-Service (DBaaS) — these latest offerings pointedly reassert the fact that databases are now part of the utility model of cloud computing.

For those planning on an early adoption, even with just two significant products (no one seems to have noticed Joyent’s Accelerator for MySQL), it could get really difficult to choose. Here’s a list of 5 things that will help you make the right choice.

1. Targeted Customers: Microsoft’s target for SQL Azure (based on extensive research, I’m sure) is business applications running in the enterprise using databases of 5GB or less. Amazon RDS, comparatively, is more flexible and targets a larger segment of users. While with SQL Azure, you can have a database of up to 10GB, Amazon RDS allows storage of up to 1TB per database instance. Microsoft advises sharding your data in case your requirement exceeds the 10GB limit, which is not really a bad idea: Sharding your data across multiple servers will scale much better than having it all on one bloated server.

2. Support for the Cloud Platform: SQL Azure is “native” to the cloud platform. What does this mean? While MySQL (which is what Amazon RDS provisions) is cloud-capable (ie, can be run on a cloud system without issues), SQL Azure was designed, from scratch, specifically for it. This can only mean that SQL Azure is poised to utilize resources available in a cloud explicitly. Perhaps in the future Amazon might think of switching to Drizzle — a fork of MySQL with the added benefit of optimizations for the cloud environment and web services.

3. Deployment: This is where SQL Azure and Amazon RDS differ the most. While many other bloggers may lead you to believe otherwise, SQL Azure doesn’t have the concept of server/database “instances”. The “servers” that you create are more logical containers than anything else. These containers are provisioned for you exclusively, and will only host your databases. There is a one-to-many relationship between a physical node in the cloud and the servers users create — several servers created by different users may be hosted on the same hardware platform in a shared environment. That is the multi-tenanted architecture implemented by SQL Azure. However, Microsoft doesn’t plan on releasing more specifics about how servers are deployed. The biggest advantage of this model is that Microsoft is able to provide SQL Azure at very low rates. On the flip side, performance enthusiasts do not get the opportunity to tailor the system to their needs. For instance, you cannot change the cache size of your database. Moreover, having a 10GB maximum limit forces a design decision on applications that require large databases. (As previously mentioned, Microsoft advises sharding — partitioning — your data into multiple databases.)

So, how is Amazon RDS different? If you look closely enough, Amazon RDS also implements a multi-tenanted architecture (it’s highly improbable that they could afford to have separate hardware set up for each user!). But this model is implemented at a very different level than that of SQL Azure’s. Amazon RDS provisions a specialized EC2 instance to your AWS account. You can then create multiple, highly varied, instances of MySQL on that EC2 instance. Database instances can vary on the basis of storage (up to an astronomical 1TB) and compute resources (up to 26 ECUs and 68GB of RAM), and you have complete control of your DB parameters (which can be changed using the APIs exposed by Amazon RDS).

4. Compatibility with Existing Systems: For the time being at least, SQL Azure supports only a subset of the features available in SQL Server. On the other hand, Amazon RDS flaunts complete support for MySQL features minus replication. If you are a fan of MySQL, chances are that your applications will work seamlessly with Amazon RDS as well. For instance, in one of my previous posts, I had described how to set up SQLyog and MONyog for an Amazon RDS DB instance. SQL Azure features support for Transact-SQL, and existing libraries — ADO .NET, ODBC and PHP — for connection.

5. Cost/Features Ratio: With all its limitations as compared to Amazon RDS, SQL Azure is definitely a cheaper solution. A notable feature in SQL Azure is that databases are automatically replicated across multiple systems providing for read scale-outs as well as a transparent fail-over mechanism in case of hardware failure — all this while Amazon RDS has specifically disabled replication on its MySQL instances. Then again, SQL Azure doesn’t feature a parallel to the unique on-demand snapshot-based backup method offered by Amazon RDS. Data in SQL Azure is automatically backed up and restored when a disaster occurs. This is transparent to the user. Users will only experience the ‘high availability’ that this feature implies. In a nutshell, SQL Azure lets you choose from two pricing schemes:

• Web Edition: Up to 1GB of storage, $9.99/month
• Business Edition: Up to 10GB of storage, $99.99/month

Additional charges include data transfer per month.
Amazon RDS gives you more choice, albeit at a premium:

• Small DB Instance: 1.7 GB memory, 1 ECU (1 virtual core with 1 ECU), $0.11/hour
• Large DB Instance: 7.5 GB memory, 4 ECUs (2 virtual cores with 2 ECUs each), $0.44/hour
• Extra Large DB Instance: 15 GB of memory, 8 ECUs (4 virtual cores with 2 ECUs each), $0.88/hour
• Double Extra Large DB Instance: 34 GB of memory, 13 ECUs (4 virtual cores with 3.25 ECUs each), $1.55/hour
• Quadruple Extra Large DB Instance: 68 GB of memory, 26 ECUs (8 virtual cores with 3.25 ECUs each), $3.10/hour

Additionally, charges for database storage actually used, I/O and storage for backups apply.

One last thought… So, which is it: SQL Azure or Amazon RDS? In my opinion that would depend entirely on the type of technology you use. If you’re primarily a Microsoft shop, then SQL Azure will be a better choice, as the technology would be familiar — you’ll get Visual Studio integration, support for .NET applications, T-SQL, etc. On the other hand, if you’re a LAMP shop, then Amazon RDS is definitely the way to go.

Shifting to a more opinionated tone, I’d like to pose this question: What could be the primary motivation behind wanting to move one’s database to the cloud? The answer, undeniably, is scalability. As your business grows, so does your database (or so they say!). While on the surface Amazon RDS looks very glossy — they have oh-so-many features, and customizations, and options — under the hood, it boils down to one thing. Amazon RDS database instances have limited scaling capability: If you create a Double Extra Large DB Instance, and you need more compute resources (ie, CPU and memory), you’ll have to change the instance type to Quadruple Extra Large and restart your database for it to take effect. What’s more, if you’ve created a Quadruple Extra Large DB instance, and your DB instance is not actually using all of the resources available, you’ll still be paying through your nose for it! SQL Azure on the other hand allows unlimited scaling at no extra cost. All you pay for is the increased data transfer.

Conversely, SQL Azure allows only up to 10GB storage. How weird is that? My PC has a database of 14GB, which I only use for testing! If you want more storage, create a new database, shard your data across the two databases, and possibly pay double the price — all when you just needed a couple of GBs extra? Phew! I’m glad I won’t be needing to hire either Amazon’s or Microsoft’s services for a while now!

For more information on SQL Azure, visit http://www.microsoft.com/windowsazure/sqlazure/.
For more information on Amazon RDS, visit http://aws.amazon.com/rds/.

Comments(6)

Change (as compared to 8.2) include:

Features:
* Now SJA will also send mail alert if job aborted due to MySQL error. Before it was only internal SJA error.
* The local port used by SSH-tunneling will now be selected automatically. This will avoid conflicts in case multiple programs use SSH. Also with Data Sync from command-line/scheduler it was possible to use same port for both connections what would effectively sync a server with itself.
* Caption for ‘Parse’ button in Notification Services Wizard was changed to make it clear that it will actually execute the statement(s) entered. There is no way to let the server parse a statement except for executing it.
* Connection windows for SSH connections will now list SSH host details in the title bar.
* Tooltips for an icon will now list the keyboard shortcut performing same action.
* The option to display ‘all’ versus a ‘LIMIT’ed set of rows in DATA tab is now table-specific and saved across sessions (note that – similar to the ‘column width persistence’ feature -  connection parameters are not  using for identifying a table; only the database name and the table name are).

Bug Fixes:
* Continously clicking the ‘Calculate’ button in Schema Optimizer in a fast manner could crash SQLyog.
* The keyword.db file (used by auto-complete and syntax highlighting) is now read only. Various validators for Windows7-compatibility would report that SQLyog wrote to “Program Files” folder at runtime (what it did not).
* When copying to clipboard an out of memory error could occur also when there was enough memory.
* The table menu will now indicate what storage engine is currently used for the table.
* Auto-complete and syntax highlighting did not recognize keywords archive, blackhole, federated, example, maria, pbxt, federatedx, falcon and mrg_myisam.
* Notifications Services/’Send Query to Email address’ option did not send a mail if an error occurred. Now a mail listing the error will be sent.
* We did not validate client-side if user specified a default value for an auto-increment column (what is invalid with MySQL).
* In DATA and RESULT tab the context menu was only working from GRID-cells. Now it also does from GRID headers and ‘whitespace’ in the tabs.
* Updating a  ’TIMESTAMP on update CURRENT_TIMESTAMP’ had no effect (the particular column was not listed in the UPDATE-statement sent by SQLyog). This was a necessary restriction before 8.13 but since we – from 8.13 – only list columns that have actually been edited by user, we can now lift this restriction.
* Import External Data – TRIGGERS could fail to update a SQL Server (n)varchar if it contained an empty string.
* If user had selected to save SSH-password locally and later changed the password, the new password was not saved – unless clicking ’save’ button in connection manager interface.
* When importing an external script with no explicit SET NAMES on top, SET NAMES latin1 was executed by SQLyog.  Now we won’t do this – and server default charset will have effect for the import in such case.
* Other small GUI fixes.

Miscellaneous:
* This release ships with an updated tunneler file for HTTP-tunneling. In the old tunneler file functions were used that are depreciated in PHP 5.3x.
* The ‘Objects’ menu was renamed to ‘Others’.

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

Comments(0)