After having updated to the latest build via Help > "Check for updates" you will be able to see more than only the result of the last SELECT query in any "Query" tab. By default, HeidiSQL displays up to 10 result sets in subtabs. In case you want more just go to

Tools > Preferences > Data

and increase this value in Maximum number of query results. Different than before, these are the first result sets from your SQL code.



Please note that HeidiSQL still does not separate multiple results from a stored procedure. Will be the next thing to implement soon.

Also a minor new feature is the hint on the lower statusbar when hovering over the MySQL version. You will see various connection, server and client related details here.

Anirudh Tamsekar made a post yesterday that laid out a few of the limitations of MySQL Cluster that seem to cause him the most pain. However his assessment of the situation is quite misleading. A few of his statements are inaccurate but more than half of the limitations he cites to are out right false. Since comments on Anirudh's blog are being moderated, I give my rebuttal here, and cite sources.

· Database names, table names, and attribute names cannot be as long in NDB tables as with other table handlers. In NDB, attribute names are truncated to 31 characters, and if they are not unique after truncation, errors occur. Database names and table names can total a maximum of 122 characters

False: "Identifiers. Formerly (in MySQL 5.0 and earlier), database names, table names and attribute names could not be as long for NDB tables as tables using other storage engines, because attribute names were truncated …

While I use this tcpdump command for MySQL query analysis with mk-query-digest, I found recently that it didn’t work on FreeBSD

$ tcpdump -i bge0 port 3306 -s 65535 -x -n -q -tttt -c 5
tcpdump: syntax error

It left me perplexed and reading the man page seemed to indicate my options were valid. I tried a few variances just to be sure without success.

$ tcpdump -i bge0 -c 5 port 3306 -x
tcpdump: syntax error
$ tcpdump -i bge0 -c 5 port 3306 -q
tcpdump: syntax error
$ tcpdump -i bge0 -c 5 port 3306 -tttt
tcpdump: syntax error

The solution was actually quite simple in the end, it had nothing to do with the commands, it had everything to do with the order of them. Placing port as the last option solved the problem.

$ tcpdump -i bge0 -s 65535 -x -n -q -tttt -c 5  port 3306

$ uname -a
FreeBSD …

Here are some tips that have been recently published on Java EE 6 & GlassFish:

Welcome to Log Buffer, the weekly roundup of database blogs. We’re back this week with a short Log Buffer #190. Only ten more issues, and we’ll be celebrating our 200th edition post.

Chen Shapira was eager to share news early this week, sending along her favorite picks on Tuesday.

Prof. Neil Gunther doesn’t like the way commercial load testing software distributes think times.

…

You might be fortunate enough to allow yourself some downtime, it is dependent on your application and business model. During this window it's possible for you to stop your MySQL daemon or lock your tables to give yourself a consistent backup of your data. Quite often this is a luxury that you cannot afford. If you are tied to a strict uptime that doesn't permit any interruption to your data availability then MySQL Replication could be the answer you need to grab that essential backup file. Once you've enabled Replication to a slave then you have the chance to backup by stopping the replication thread and  mitigate the risk of corruption whilst securing your latest dataset. Using the slave will also negate any overhead a backup like mysqldump would have on your active Master server.

Although in this case we are deploying Replication to take consistent backups of our data, there are many uses for the mechanism such as scaling out …

Recently Kostja posted two insightful blog posts about his thoughts on the currently fragmented MySQL landscape and quality of a piece of code contributed by a “community member”, which is a MySQL euphemism for a person not employed by MySQL. (Hence, the full time MySQL developers are themselves not members of their own community?)

I wanted to comment on both posts, but found out Kostja only allows logged in LiveJournal users to comment, which I am not. Since the posts were interesting enough, I suppose they deserve a comment in a new blog post like this instead.

From “RDBMS software is difficult” (slightly reordered)

The main reason it is harder to do changes with MySQL is a …

One thing I haven't seen anybody commenting on is the fact that with SAP acquiring Sybase, it will be the last major independent database company to be merged into a larger SW company. (To say this, you can qualify MySQL AB as a major database company, but disqualify, say, EnterpriseDB or InterBase, which imho is entirely reasonable.)

read more

These are the slides to a talk I did earlier this week for students of the professional bachelor in ICT course at KaHo St. Lieven. I wanted to give a clear and simple introduction to the memcached service, as I think it’s an invaluable tool in today’s web development.

In one of the previous articles I discussed performance of the three methods to implement an anti-join in MySQL.

Just a quick reminder: an anti-join is an operation that returns all records from one table which share a value of a certain column with no records from another table.

In SQL, there are at least three methods to implement it:

LEFT JOIN / IS NULL

SELECT  o.*
FROM    outer o
LEFT JOIN
        inner i
ON      i.value = o.value
WHERE   i.value IS NULL

NOT IN

SELECT  o.*
FROM    outer o
WHERE   o.value NOT IN
        (
        SELECT  value
        FROM    inner
        )

NOT EXISTS

SELECT  o.*
FROM    outer o
WHERE   NOT EXISTS
        (
        SELECT  NULL
        FROM    inner i
        WHERE   i.value = o.value …