In short, yes. Read my blog post that I linked to. I explained the whole thing and even provided code samples you can use to reproduce it on your own server. But basically you have it right-- the data in the table had to be converted one row at a time which defeated the index.
~Brad -------- Original Message -------- Subject: Re: Maybe I need a SQL Service Consultant... From: Judah McAuley <ju...@wiredotter.com> Date: Sat, February 14, 2009 6:41 pm To: cf-talk <cf-talk@houseoffusion.com> So you are saying it wasn't that the index was a different codepage than the column but rather that the data stream had to be converted because the data was coming in as Unicode? I can see that. Obscure but I can see it. Judah On Fri, Feb 13, 2009 at 10:41 PM, Brad Wood <b...@bradwood.com> 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:319336 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
