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:319325 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
