Windows 7, 64 bit

Quote from wlad's comment to CONJ-117:

I think "Illegal mix of collations" is a problem.
I reproduce it from the command line client , and you should be able too.

create table h( c varchar(10) character set ascii);

select * from h2 where c='ä'; # any non-ascii character will work

gives

ERROR 1267 (HY000): Illegal mix of collations (ascii_general_ci,IMPLICIT) and (cp850_general_ci,COERCIBLE) for operation '='

The original problem was involved prepared statements (JDBC client-side), and UTF8 as the client side encoding, and latin1 column on the server side, but the essence of the problem is that if you have a character in the query outside of column encoding range, this ugly "Illegal mix" arises. Why would not the query just return an empty set.
There is another part of the bug, Marcel states he was able to insert non-latin1 into latin1 column, but I was not able to reproduce it .

Since we have a charset expert in the house, I'll leave it to bar to say whether it's really a bug.

Marcel was able to insert non-latin1into latin1 column, mostly likely due in non-strict sql mode, in which server replaces unknown byte sequences with question marks. So it is well possible to "insert" string into a column (at least there is no exception, so it kinda succeeds ), but impossble to query for it afterwards -there is an exception

> There is another part of the bug, Marcel states he was able to insert non-latin1 into latin1 column, but I was not able to reproduce it .
> Marcel was able to insert non-latin1into latin1 column, mostly likely due in non-strict sql mode, in which server replaces unknown byte sequences with question marks

Just to clarify this: I do not consider (the insert) this a bug: In fact I think this is expected behaviour. I've seen the same behaviour (replacing unknown chars to question marks) on oracle.

Doesn't seem to be a bug. When collations are incompatible, the server cannot return an empty set, because it does not know how to compare two values. May be they match. May be they don't. The server cannot perform a comparison.

I'm do not completely follow the argumentation. logically, comparing strings does not seem a big deal. so, one string is cp850, another string is ascii, cp850 includes all ascii, thus one can convert ascii to cp850, which is a nop-conversion, and compare them using cp850_general_ci rules.

yes, it's a slightly different issue.
Perhaps, ascii_general_ci and cp850_general_ci could be compatible. bar, any thoughts?