> Thanks for the explanation, I was wondering because I am able to
> reproduce bug#34479, that we discussed on the Friday conf. call even
> without adding indexes to the field.
I've got a guess on that. UCS2 is not one of the character sets
Jim uses a lot - he's distinctly a UTF-8 kind of guy, and I think
that encode data may be handling trailing 0x20 bytes incorrectly
What I would do is follow a UCS2 string that ends in a 0x20 through
encodeRecord and encodeOpaque and see if it loses its trailing byte.
If so, when decoded, you're likely to get whatever happens to be in
the buffer as the second half of the last character.
Which reminds me that in general, using UCS2, the code that
truncates blanks needs to look for pairs of 0x20 0x00, not
0x20 bytes. And the other fixed size, multi-byte character
sets need special handling as well.