Bit Format

[zTodd]

Is there a way to change the way bit(1) fields are shown? When I import from an Access database file into MySQL using the migration tool, the yes/no fields in Access came over as bit(1) and not null, which caused Access to say ODBC insert failed when I linked back to the tables, even when I put in 0 for those fields- after I made them Not Null in SQLYog then Access could insert a row just fine.

But the only thing now is that when I look at the data in SQLYog it shows those fields as a little box for where they = 1 (yes or -1 in Access) or as “(Binary/Image)” for where they = 0 (no or 0 in Access) – can I make it show bit(1) fields as 0 or 1, or true or false, or yes or no, without writing queries every time to do it? Thanks for any input!

They show up in Access fine as 0 or -1, but we just wanted to know if we could get SQLYog to show them better.

[peterlaursen]

It is a known issue.  We do not support  the BIT type- -whether bit(1) or bit(n)  (n can be up to 64).   Please refer to http://code.google.com/p/sqlyog/issues/det…mp;can=2&q= .  I suggest you try to map to a TINYINT when importing.  That is what MySQL before 5.x is doing.

I do not think you will ever be able to 'link back to access' from MySQL BIT types.  This is basically an issues with incompability between the MyODBC driver, MySQL and Access.  Access has no datatype similar to MySQL BIT.

And Why do you want to 'link back' ?  something you miss in SQLyog?

What is required is a true implementation of the standard SQL BOOL type.  Neither Access nor MySQL has (though Access is closer than MySQL!).  That is the basic problem!  MySQL BIT is not a boolean!  It is a numerical type using the binary number system.  In MySQL command line you enter a BIT(4) as for instance

Code:

b'1001'

.  This we should support in SQLyog and we should also display it like that! (what mysql command line client does not!)  Just as I think (my personal opinion) that a VARBINARY(8) should be displayed as for instance h'A0 34 F1 AA E7 2C 00 EA'  (h for 'hexadecimal') similar to common hex-editors .

So basically a BIT(1) is no better or 'more correct' substitute for a true BOOL than a TINYINT(1) is!!

Support for BIT type is priority once we get the first stable 6.0 release out!

[Author]

Posts