免责声明：我知道这个问题以前已经被问过一百次了，但是我只是想检查一下，在我继续之前，我可能已经错过了一个更简单的解决scheme，并且写了很多代码。
我们的软件使用最初为SQL Server 7devise的数据库，因此，所有创build它的脚本都不会为任何字符列指定任何明确的归类。 相反，当数据库创build/还原到SQL Server 2000或更高版本时，每个列都会inheritance数据库归类（恰好是SQL_Latin1_General_CP1_CI_AS因为这是SQL Server 7的默认值）。
从理论上讲，这并不重要，因为如果我们的数据库是从客户的服务器上重新创build的，它会inheritance客户的服务器sorting规则（通常是现代安装默认值Latin1_General_CP1_CI_AS ），一切正常。 但是，这种情况在向我们发送数据库备份时发生故障，或者我们向他们发送数据库备份，并且无论代码何时尝试访问临时表等，我们或他们都会遇到可怕的sorting规则不匹配错误。
我们已经尝试教育客户安装或重build他们的SQL Server实例来使用我们首选的sorting规则，但是这当然并不总是会发生，并不总是可能的。
涉及到创build新数据库和复制数据的解决scheme对于我们来说并不实际，我们需要一个“魔棒”，我们可以在实时数据库中进行波动，以便在不影响数据的情况下就地校正所有列。 我正在考虑编写一个实用程序来做到这一点，但由于这将是一个相当大的工作，有没有人有任何简单的build议？
一种select是“校对”你的代码与sorting不匹配。
您可以使用特殊归类“DATABASE_DEFAULT”强制不知道实际归类是什么。 您可以在需要使用的临时表，表variables和系统表中的chartypes列上使用它。
例：
CREATE TABLE #Currency (CCY CHAR(3)) GO INSERT #Currency VALUES ('GBP') INSERT #Currency VALUES ('CHF') INSERT #Currency VALUES ('EUR') GO SELECT Something FROM myTable M JOIN #Currency C ON M.CCY = C.CCY --error! GO -- in join too SELECT Something FROM myTable M JOIN #Currency C ON M.CCY = C.CCY COLLATE DATABASE_DEFAULT --no error GO DROP TABLE #Currency GO CREATE TABLE #Currency (CCY CHAR(3) COLLATE DATABASE_DEFAULT) GO INSERT #Currency VALUES ('GBP') INSERT #Currency VALUES ('CHF') INSERT #Currency VALUES ('EUR') GO SELECT Something FROM myTable M JOIN #Currency C ON M.CCY = C.CCY --no error! GO DROP TABLE #Currency GO
这也意味着，当你的客户将数据库迁移到另一个不同的sorting规则的新的SQL Server复制框时，它也可以工作。
简短的回答是不是一个简单的方法。 我过去也有同样的问题。
我想说的是2件事情，首先当你的客户给你发送一个意外sorting的数据库时，安装一个新的SQL实例，并使用一个默认的sorting规则来匹配他们的数据库并在其中工作。
其次是确保您的应用程序将与其他sorting规则，然后是默认值（因为那些将来可能会改变），并且只要SQL服务器和数据库上的sorting规则匹配，就可以正常工作。 然后，让客户安装一个与他们的数据库匹配的sorting规则的SQL服务器就相当容易了，然后就可以工作了。
或者写一个实用程序来更新数据库中的所有表等等，正如你所说的那样，但是如果你想的话可能会更有效。
如果数据库中的所有列具有相同的sorting规则，那么在进行跨数据库查询时（或者您的应用程序对sorting非常敏感），这只会对您造成问题。
当您意识到join到临时表是跨数据库，因为它们在tempdb中，粘滞点来了。 这很容易sorting – 只要确保临时表中的任何文本列都使用COLLATE database_default指令显式创build。 这意味着该列将使用当前数据库的默认sorting而不是tempdb的默认sorting（与服务器的默认sorting相同）来创build。