Hi,
Regarding this bug
,https://sourceforge.net/tracker/index.php?func=detail&aid=981359&group_id=23067&atid=377408
once again we face the problem of interpreting just what is meant by BINARY.
Exporting the mysql.user table, which, depending on the version, has
some fields marked BINARY, causes a problem *seeing* the expected
results, because they are in 0x format. Of course the correct data is there.
In MySQL:
As of MySQL 4.1, values in CHAR and VARCHAR columns are sorted and
compared according to the collation of the character set assigned to the
column. Before MySQL 4.1, sorting and comparison are based on the
collation of the server character set; you can declare the column with
the BINARY attribute to cause sorting and comparison to be case
sensitive using the underlying character code values rather then a
lexical ordering. BINARY doesn't affect how the column is stored or
retrieved.
http://dev.mysql.com/doc/mysql/en/CHAR.html
So, in the intention of MySQL's authors, BINARY does not mean that the
contents is binary.
In libraries/export/sql.php:
} else if (stristr($field_flags[$j], 'BINARY')) {
$values[] = '0x' . bin2hex($row[$j]);
As the user suggests, should we add an option "Use hexadecimal format
for BINARY" ?
Marc