Do you know the fine details of MySQL’s transactional error handling with the InnoDB storage engine? If you’re writing transactional SQL, you need to be prepared to handle errors appropriately, and to do that, you need to know how MySQL handles them. This article introduces you to the topic. How InnoDB differs from other engines When a MySQL query has an error in a non-transactional storage engine, such as MyISAM, the results are anybody’s guess.

There's an interesting survey of Red Hat's partners by Bank of America that crossed my desk recently.  Ok, I admit, I have been burried for the last couple of months; the survey was from June and I should have picked up on it earlier since it's been covered by both Forbes and Matt Asay's blog over at InfoWorld.  (Ok, I don't usually find Forbes all that great a read; too old school for me.  But how did I miss Matt's posting?)  Still, it's quite interesting reading, especially in light of Red Hat's introduction of a software stack. 

Bank of America Securities spoke to 130 Red Hat partners across all …

The development of Connector/ODBC v5 has been ODBC Centric. Who cares and how important is this distinction?

The folks who care the most are those that get into the C/ODBC code in the hopes of tracing down a bug or otherwise enhancing the code. You see; developing C/ODBC with an ODBC centric frame-of-mind means that anyone who understands the ODBC specification, even superficially, will find the code approachable. Presumably anyone using the ODBC driver will have some understanding of ODBC and certianly those savy enough to dive into the C/ODBC code.

The different frame-of-mind manifests itself in a wide variety of ways all of which makes cross-referencing to the ODBC specification much easier. For example;

• Naming conventions, from files to variables, are more meaningfull from an ODBC perspective.
• Reduction and isolation of references to MySQL specific code (loose coupling) reduces need to understand both …

I have been a consultant for long time. It is an interesting job, which has given me much satisfaction. The coolest part of the job is the inner pleasure you feel when you solve a difficult problem in a few minutes, earning a reputation for being a wizard.
The negative part of the job is being alone. As a consultant, you are supposed to know everything, and as such you don't have anybody to talk with when you have doubts (and if you are really good you must have doubts from time to time). Well, this condition makes you stronger, and improves your confidence, but your interaction with your co-workers is quite weak.
So I decided to try a new career for a change, and to cash on my experience and knowledge of databases in general and MySQL in particular. And which position should be more suitable than one at MySQL AB itself?
I applied for a couple of jobs at MySQL, got two offers, chose the one that appealed me the most, and here I am. …

I was reading this article today about William Gallas, the fullback that Arsenal pulled away from Chelsea just before the transfer window closed (what a great replacement for whiner Ashley Cole). The article quotes Arsene Wenger, Arsenal's brilliant coach, who mentioned an article that talks about commonalities between winners. I tracked down the article, and was surprised to find out that the coach who walks on water also reads...

USA Today, the McNewspaper of the US. The article comes from USA Today. Ugh.

Still, I managed to hold my snobbish nose long enough to read the article, and found it useful. What separates the winners (in athletics) from the also-rans? What are the commonalities of winning …

I am glad to see all of the advanced features in MySQL. They all have their place, whether it's making things possible that weren't before, or improving ease-of-use, or improving thru-put and performance. However I find that just because you can use an advanced feature in place of the old way doesn't necessarily mean that you should.

If there are several ways to accomplish the same thing, my first inclination is to go with the one that is simplest to code. My philosophy is that if I arrange the syntax in a logical order with each link in the chain in its proper place, that this will make it that much easier for the server to optimally execute it.

I think that some people will code a subquery in preference to the equivalent join syntax mostly from a basic lack of understanding of how joins work. My personal preference is to code something as a join and avoid use of subqueries wherever possible. If the …

For certain evil purposes last week, I assembled the old Saturn with a hard disk I found when cleaning a little while ago (I have that kind of tech stuff - you clean up and find 40GB disks - I’m pretty sure I have an 8.4 bumming around somewhere too).

I ended up being able to do the evil I needed to, but I could tell that the room was a bit warmer due to the extra box being alive. I was also lazy and couldn’t be bothered going downstairs for the D200, so this was shot with my old and trusty Coolpix 4500.

I used the box to be able to get remote access to a customers’ test setup to do some diagnosis on a bug (that’s notoriously hard to reproduce). I think I have a fair idea of what it is now though (timing related - not fun).

Remember kids, threads are evil.

Also, an interesting thing to …

It's past 7 o'clock in the morning, but this night has been a productive one (hey - no bad thinking please ;-)).

I have updated db4free.net to the latest MySQL 5.1 development source version (5.1.12-beta) and discontinued the 5.0 server. The "former" 5.1 server which ran on port 3307 is still alive, but no new accounts are being created there anymore. During the next days I plan to make the databases that run on the port 3307 server accessible on the main 5.1 server (with standard port 3306) to have everything together on one server - and let the port 3307 server die.

Before the update, most users have only used the 5.0 server, but only a little number of users did anything on the 5.1 server. My intention is to test 5.1 more intensively under a higher load and I hope that this also helps to contribute to the development of MySQL 5.1 by finding bugs or other flaws on a …

It's been some time since I last blogged. I've been quite busy erasing all the
bugs from the partitioning implementation in MySQL 5.1. At the moment
there is 1 bug left in review and a few on its way into the main clone. The
rest of the bugs are fixed and already in the 5.1 clone. So the next 5.1
release (5.1.12) will have partitioning ready for tough tests. So if you have
been waiting for partitioning to stabilise it's time to try it out now with your
application and see how it works.

I watched an interesting animation my daughter made about how partition
pruning using dynamic PowerPoint slides. Really interesting to see what can
be done if one knows how to handle these types of tools. She's quickly
becoming our family authority on presentations.

Lately we've also started working on some extensions for the partitioning
hopefully ready for 5.2. We …

What format do you use to store data during transport?

I had a problem, I needed to pull data from one website system, into another. Where is the data? Its in MySQL, so I decided to skip the API for the system I am exporting the data from and instead just extracted the data from the database (and yes... I will use the API for reinserting the data... I don't want to break the business logic of the new system).

That was an easy decision.

Then I asked myself, what do I store the data in during the conversion? I needed some format because the old web site is not kept on the same system as the new. So I was going to need a flat file for a bit of time.

The first answer that came to mind?

XML!

So for the last couple of weeks I have been thinking about how I was going to design the XML schema. Not putting a lot of thought into this, just jotting down notes in my …