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. -- D. Richard Hipp <[EMAIL PROTECTED]>
