Can you provide some details of the data returned from you do the = get_range() ? It will be interesting to see the raw bytes returned for = the keys. The likely culprit is a change in the encoding. Can you also = try to grab the bytes sent for the key when doing the single select that = fails.=20
You can grab these either on the client and/or by turing on the logging = the DEBUG in conf/log4j-server.properties Thanks Aaron On 4 May 2011, at 03:19, Henrik Schröder wrote: > The way we solved this problem is that it turned out we had only a few > hundred rows with unicode keys, so we simply extracted them, upgraded to 0.7, > and wrote them back. However, this means that among the rows, there are a few > hundred weird duplicate rows with identical keys. > > Is this going to be a problem in the future? Is there a chance that the good > duplicate is cleaned out in favour of the bad duplicate so that we suddnely > lose those rows again? > > > /Henrik Schröder
