Unsigned integer values are used in a database when you only expect to contain positive values and no negative values (less than zero). If you know a certain field will never legitimately contain negative values, then this is actually the most efficient field type to select.

There is a catch with unsigned ints however that can create problems for you if you’re not careful. That is, when you subtract unsigned ints, you will always get a positive value back no matter what. What does that mean?

Say you have a table for products with two unsigned fields: qty_in_stock and qty_sold. Lets assume for whatever reason you oversold your inventory and qty_in_stock now equals 100, but qty_sold = 101. So take the following statement:

SELECT qty_in_stock - qty_sold as qty_remaining FROM products

You would expect qty_remaining to be -1, right? Wrong! In fact MySQL returns 18446744073709551615 !

Why would this happen? Well, because MySQL is built so that when you perform a math operation on two unsigned ints, it will always return an unsigned int. And -1 is technically an out-of-bounds value for an unsigned field type. Instead of complaining, MySQL returns the value that would have represented -1 if it were unsigned which is 18446744073709551615.

Mathematically, I suppose this is correct, however it doesn’t make any logical sense to me. If anything, I think MySQL should throw an out-of-bounds error when this happens because the default behavior seems very unintuitive to me. It is as though they are trying to say that one positive value subtracted from another can never result in a negative value. Of course this is false, but that is how MySQL works.

There are two solutions to this. The first is to simply use signed ints if you ever expect them to be used in a subtraction formula. You waste some space, but it’s an easy fix.

The second solution is, if you are able to edit your SQL statement that have the subtraction, you can use the MySQL cast function. The example from above could be converted to the following:

SELECT cast(qty_in_stock - qty_sold as signed) as qty_remaining FROM products

So there is a solution to this “problem” if you will. You can read more about this subject on the MySQL site at http://dev.mysql.com/doc/refman/4.1/en/cast-functions.html

Share This

MySQL auto-id function provides the ability to automatically create a new id for each new record on insert.  This works great for unique ids, but sometimes more logic is required.

For a recent assignment we needed to populate a table that reflects seating in a stadium.  The seating was typical of most venues consisting of Aisles and Seats.  For example, A-1, A-2, A-3, B-1, B-2, B-3, and so on. When the table was initially populated, the seat_number field was all set at it’s default value of ‘1′.  So we needed sequential numbers for the seats, but the count had to start over with each new Aisle.  This could have been done easily in a scripting language, but what fun is that!  We wanted to accomplish the numbering in one regular SQL statement.

This problem would be easily solved using Oracle’s rownum functionwhere we can get a sequential id for each row within a resultset.  But, alas, MySQL doesn’t have a rownum function.  What we did find, however, is a wonderful hack on Mark Malakonov’s blog that duplicates this functionality for MySQL.

The final query, which only updates Aisle ‘A’ is here:

update venue_seat set seat_number =
(select @rownum:=@rownum+1 rownum FROM (SELECT @rownum:=0) r)
where aisle = 'A'


These fields obviously relate to a specific schema, however the @rownum trick can be used to generate sequential numbers for your tables as well. If you need to update or populate a table with sequential numbers but need some additional logic, this is a handy trick to have in your toolbox.

Share This

MySQL Error Number 1005
Can’t create table ‘.\mydb\#sql-328_45.frm’ (errno: 150)

If you get this error while trying to create a foreign key, it can be pretty frustrating. The error about not being able to create a .frm file seems like it would be some kind of OS file permission error or something but this is not the case. This error has been reported as a bug on the MySQL developer list for ages, but it is actually just a misleading error message.

In every case this is due to something about the relationship that MySQL doesn’t like. Unfortunately it doesn’t specify what the exact issue is. Here is a running list of causes that people have reported for the dreaded errno 150. I’ve tried to put them in order based on the frequency that I hear about a particular cause.

You may want to start by running the MySQL command “SHOW INNODB STATUS” immediately after receiving the error. This command displays log info and error details. (Thanks Jonathan for the tip)

Known Causes:

1. The two key fields type and/or size doesn’t match exactly. For example, if one is INT(10) the key field needs to be INT(10) as well and not INT(11) or TINYINT. You may want to confirm the field size using SHOW CREATE TABLE because Query Browser will sometimes visually show just INTEGER for both INT(10) and INT(11). You should also check that one is not SIGNED and the other is UNSIGNED. They both need to be exactly the same. (More about signed vs unsigned here).
2. One of the key field that you are trying to reference does not have an index and/or is not a primary key. If one of the fields in the relationship is not a primary key, you must create an index for that field. (thanks to Venkatesh and Erichero and Terminally Incoherent for this tip)
3. The foreign key name is a duplicate of an already existing key. Check that the name of your foreign key is unique within your database. Just add a few random characters to the end of your key name to test for this. (Thanks to Niels for this tip)
4. One or both of your tables is a MyISAM table. In order to use foreign keys, the tables must both be InnoDB. (Actually, if both tables are MyISAM then you won’t get an error message - it just won’t create the key.) In Query Browser, you can specify the table type.
5. You have specified a cascade ON DELETE SET NULL, but the relevant key field is set to NOT NULL.  You can fix this by either changing your cascade or setting the field to allow NULL values. (Thanks to Sammy and J Jammin)
6. Make sure that the Charset and Collate options are the same both at the table level as well as individual field level for the key columns. (Thanks to FRR for this tip)
7. You have a default value (ie default=0) on your foreign key column (Thanks to Omar for the tip)
8. One of the fields in the relationship is part of a combination key & does not have it’s own index. You must create a separate index for the key field in order to use it in a constraint. (Thanks to Alex for this tip)
9. You have a syntax error in your ALTER statement (Thanks to Christian for the tip)

The MySQL documentation includes a page explaining requirements for foreign keys. Though they don’t specifically indicate it, these are all potential causes of errno 150. If you still haven’t solved your problem you may want to check there for deeper technical explainations.If you run into this error and find that it’s caused by something else, please leave a comment and I’ll add it to the list.

Share This