Microsoft is very COM-based for its actual data access methods.... and COM
uses BSTRs that are BOM-less UTF-16. Because of that, the actual storage
format of any database ends up irrelevant since it will be converted to
UTF-16 anyway.

Given that this is what the data layers do, performance is certainly better
if there does not have to be an extra call to the Windows
MutliByteToWideChar to convert UTF-8 to UTF-16. So from a Windows
perspective, not only is it no trouble, but it also the best possible
solution!

In any case, I know plenty of web people who *do* encode their strings in
SQL Server databases as UTF-8 for web applications, since UTF-8 is their
preference. They are willing to take the hit of "converting themselves"
because when data is being read it is faster to go through no conversions at
all.

Michael

> ----------
> From:         [EMAIL PROTECTED][SMTP:[EMAIL PROTECTED]]
> Sent:         Friday, June 23, 2000 7:55 AM
> To:   Unicode List
> Cc:   Unicode List; [EMAIL PROTECTED]
> Subject:      Re: Java, SQL, Unicode and Databases
> 
> 
> 
> I think that this is also true for DB2 using UTF-8 as the database
> encoding.
> From an application perspective, MS SQL Server is the one that gives us
> the most
> trouble, because it doesn't support UTF-8 as a database encoding for char,
> etc.
> Joe
> 
> Kenneth Whistler <[EMAIL PROTECTED]> on 06/22/2000 06:42:20 PM
> 
> To:   "Unicode List" <[EMAIL PROTECTED]>
> cc:   [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] (bcc: Joe
> Ross/Tivoli
>       Systems)
> Subject:  Re: Java, SQL, Unicode and Databases
> 
> 
> 
> 
> Jianping responded:
> 
> >
> > Tex,
> >
> > Oracle doesn't have special requirement for datatype in JDBC driver if
> you use
> UTF8 as database
> > character set. In this case, all the text datatype in JDBC will support
> Unicode data.
> >
> 
> The same thing is, of course, true for Sybase databases using UTF-8
> at the database character set, accessing them through a JDBC driver.
> 
> But I think Tex's question is aimed at the much murkier area
> of what the various database vendors' strategies are for dealing
> with UTF-16 Unicode as a datatype. In that area, the answers for
> what a cross-platform application vendor needs to do and for how
> JDBC drivers might abstract differences in database implementations
> are still unclear.
> 
> --Ken
> 
> 
> 

Reply via email to