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