Wow! I didn't know that. So would it be safer to use all nchar fields in the database instead of char, then no matter what the paramater came in as, it is faster to convert the parameter to unicode once than to convert every value in the index?
At 01:41 AM 2/14/2009, you wrote: >This isn't a bug in SQL Server. Rick said that his primary key column was a >char field and so was the index. Since Unicode support was enabled, >parameters were coming in as nchars or nvarchars. >SQL Server cannot compare a char to an nchar so it must convert one so the >data types match. > >http://www.codersrevolution.com/index.cfm/2009/2/13/SQL-Server-Gotcha-Implicit-Unicode-Conversion > >~Brad > > > > That's fascinating. But why would sql server create an index in a > > codeset that didn't match the column? You'd think that the index would > > match the declared type of the column automatically. I would think of > > that as a bug in sql server. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;207172674;29440083;f Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:319309 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
