I found a problem using NET connector 5.0.8.1 and version MySQL version 5.1.22 (so it persists). My problem was that data in a column defined as BIT was appearing as ‘1′ when I selected the table with a simple select statement, but appeared as ‘0′ when I added a LEFT JOIN to another table !!! I have moved this column to TINYINT. And now I need to fix a load of other columns previously defined as BIT.

Using the MySQL .NET connector (5.1.4), and running a SELECT query that returns a column of BIT type, I could find no valid cast to retrieve the value of the column into a variable in my C# code. I tried bool, Byte, and Int16, and it always threw the exception “The specified cast is not valid.” I didn’t try the larger integers, assuming they wouldn’t work either.

In fact, I ran across this blog while searching for a solution to this problem.

For instance:

MySqlCommand cmd = MySqlConn.CreateCommand();
cmd.CommandType = CommandType.Text;
cmd.CommandText = “SELECT bitField FROM myTable”;

MySqlDataReader dr = cmd.ExecuteReader();
Object ob;
while (dr.Read())
{
if ((ob = dr[0]) != DBNull.Value)
bool BitField = (bool)ob;
}

gave me this exception, as did making BitField a Byte and Int16 type and trying those casts. I also tried simply doing BitField = (bool)(dr[”bitField”]); Same result.

Once I changed the column type to TINYINT and my code variable type to Byte, it worked fine. So thanks!

(I would submit this as a bug to MySQL, but they would just say “That’s the way it was designed, therefore it’s not a bug.” Uh huh…)

(Consulting Webster to find out whether “cat” is synonymous with “feline”… or is this a trick question?)

I hope he/she loves bitmasks because they truly provide a necessary performance or storage advantage.

…As opposed to bad reasons for loving them, e.g.:

• They are nifty (which they are, no doubt!)
• They are a vestige of an old architecture from the days when storage and CPU cycles were not so cheap.
• They are a vestige of an old mentality from the days when storage and CPU cycles were not so cheap.

In a general sense, here in “modern times”, I think individually named columns/variables are a superior solution. I think in the vast majority of cases, the potential performance and storage gains of bitmasks are at least negated, if not outweighed, by the readability — and thus maintainability — difficulties they pose. (I mean … if simple magic numbers are bad, then these, which are essentially compound magic numbers, must be compound bad!)

Just one man’s considered opinion…

Now off to convert all my BIT columns to TINYINTs!

For ColdFusion Users: an updated MySQL Connector/J allows ColdFusion to connect to MySQL 5, but does not seem to play well with these new MySQL BIT fields (at least as of now). Using TINYINT instead of BIT seems to be the best work-around.