On Thu, 2003-10-23 at 13:31, Wayne Venables wrote:
> Unfortunately that still means there is a performance hit converting all
> data in and out of the library from UTF-8 to UCS16. A large number of
> operating systems and programming languages store strings natively as UCS16.
Even if you meant larger than 1% of operating systems AND languages store strings
natively as UCS16, you'd still be incorrect.
I believe compiling sqlite for UTF-8 should solve my problems. Just have to pay the conversion price.
But just for the sake of argument, I will respond. Win32 is unicode (UCS16). Writing C/C++ w/ Win32 generally involves using wide char strings. Visual Basic natively stores strings as unicode. Java natively stores strings as unicode. I'd say that covers a lot more than 1%. And if you're coding for a non-unicode operating system, I sure hope you're using unicode anyway or otherwise you're alienating a large portion of users. I purely ASCII database in this day and age is terribly backwards. Thankfully, sqlite has the UTF-8 option.
Later,
Programmer/Analyst WebMotif Net Services, Inc. 1.800.332.WIPS Direct: 604.299.1908 [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
