Am 02.02.2006 um 12:51 schrieb [EMAIL PROTECTED]:
Jens Miltner <[EMAIL PROTECTED]> wrote:
Regarding the checkin comment from the fix for ticket 1654:
Always register BINARY collating sequences for UTF-16BE and
UTF-16LE both. Formerly we were only registering the native byte
order by default. Ticket #1654 . Note: There may still be problems
with collating sequence synthesis. (By drh)
Does this mean this specific problem is solved, but other similar
problems may still exist and they just didn't surface with this
specific database?
What exactly is the "collating sequence synthesis"?
And what was the trigger for the crash? Was it the use of ALTER
TABLE, or was it just related to UTF-16BE/UTF-16LE?
Formerly, SQLite only had built-in BINARY collating sequences
for UTF-8 and UTF-16 in the native machine byte order. Bug #1654
was caused when running on a little-endian machine (thus registering
a UTF-16LE collating sequence) while reading a big-endian database.
I solved it by registering three different BINARY collating sequences
for the three different encodings.
SQLite is *suppose* to be able to generate its own collating
sequences for different encodings. Thus if you give it a UTF-16LE
collating sequences, it is suppose to be able to generate a
UTF-16BE collating sequence from this automatically. It is this
auto-generation of collating sequence that I suspect is busted.
As long as you register all the collating sequences you need
with the same byte encoding as the database uses, you should not
have any problems.
Thanks for the info. (and for the fast fix!)
</jum>
