3.2w+
社区成员
- 主页
- 基础类
- 应用实例
- 新技术前沿
把SQL SERVER 2000的数据库恢复到SQL SERVER 2005上去后，执行存储过程出错。
把SQL SERVER 2000的数据库恢复到SQL SERVER 2005上去后，执行存储过程出错。
出現以下錯誤提示：
無法解析 equal to 作業中 "Chinese_Taiwan_Stroke_CI_AS" 與 "SQL_Latin1_General_CP1_CI_AS" 之間的定序衝突。
说是后面加collect Chinese_Taiwan_Stroke_CI_AS可解决。
因有很多存储过程，这样一个个去改，不是很麻烦？有没有更好的办法解决？
出現以下錯誤提示：
無法解析 equal to 作業中 "Chinese_Taiwan_Stroke_CI_AS" 與 "SQL_Latin1_General_CP1_CI_AS" 之間的定序衝突。
说是后面加collect Chinese_Taiwan_Stroke_CI_AS可解决。
因有很多存储过程，这样一个个去改，不是很麻烦？有没有更好的办法解决？
...全文
当前发帖距今超过3年，不再开放新的回复
发表回复
sanduVB 2007-12-25
我的数据库是繁体的，操作系统也是繁体的。排序规则应是 "Chinese_Taiwan_Stroke_CI_AS"，数据库属性中反映也是如此。应不是通过改变这个属性来解决问题。有没有其它更好的办法？
sanduVB 2007-12-24
有人能有好的解决办法吗？
sanduVB 2007-12-24
说来说去，有谁能帮我提供一个好的解决办法呢？
sanduVB 2007-12-24
说来说去，有谁能帮我提供一个好的解决办法呢？
云中客 2007-12-22
不同的系统难免会出现语法上的不同
w2jc 2007-12-22
学习一下
-狙击手- 2007-12-21
排序问题
dawugui 2007-12-21
在SQL Server 2005中升级存储过程
作者：Serdar Yegulalp 2007-05-29
《SQL Server 2005的变化》一文中揭示了SQL Server 2005的变化如何打破了旧有的应用程序和数据库，特别是使用被抛弃的函数的地方。现在我将要讨论的是如何在你的移植过的数据库里面使用存储过程来充分利用这个SQL Server2005中的新函数，而不需要打破现有的功能性。
我们假设你有一个前端的应用程序，是由不同的团队来分别写入或者管理，并且它不像后台数据库那样频繁更新。你想要在SQL Server应用程序的存储过程中进行修改以充分利用新的功能。你还想要这个过程尽量温和，这样数据库和前端应用程序就都不会突然崩溃。
例如，你想要更新存储过程来使用SQL Server 2005的T-SQL中一些新的功能，例如TRY and CATCH函数，这个函数可以让复杂的错误追踪变得简单一点。你通常会拷贝现有的存储过程到一个新的并行的存储过程里面去，然后对它进行更新，使用新的功能，然后或者在经过修改的前端应用程序版本，或者查询分析器中测试两方面的行为。
当你很自信新的存储过程的行为是正确的，并且它也准备好用在产品中，你就可以无缝的替换它，例如通过修改两个存储过程的名字，或者通过代码的拷贝。我个人倾向于修改名字，因为这可以让你对原有的代码做个备份——像你的数据库中的其它东西一样，做个备份，以防出现不可预期的问题。
这是相对标准的技术，但是我曾见过的更有意思的一个问题涉及了可选参数传递：
CREATE PROCEDURE my_procedure
{其它的参数在这里},
@optionalparameter Boolean=FALSE
AS
If @optionalparameter=TRUE
Begin
{带有SQL Server 2005-特定命令的新版本的存储过程放在这里}
End
Else
Begin
{旧版本的存储过程放在这里}
End
还有另外一种有用的方式来选择性的测试代码。现有的前端对存储过程的呼叫不会使用可选参数，还会执行原来的代码。你可以在这里使用新的前端代码来测试存储过程，然后优雅地更新对现有存储过程的参考。因为参数是可选的，所有现有的对存储过程的呼叫(例如那些没有参数的呼叫)都会像以前一样准确地传递过去。
如果你不能添加新的存储过程，但是可以修改现有的存储过程的话，还有一种在这种限制下的好办法。当没有保留历史遗留代码的时候，你可以在存储过程中逐步淘汰IF。最后，在存储过程和你的前端代码中逐渐放弃可选参数。
作者：Serdar Yegulalp 2007-05-29
《SQL Server 2005的变化》一文中揭示了SQL Server 2005的变化如何打破了旧有的应用程序和数据库，特别是使用被抛弃的函数的地方。现在我将要讨论的是如何在你的移植过的数据库里面使用存储过程来充分利用这个SQL Server2005中的新函数，而不需要打破现有的功能性。
我们假设你有一个前端的应用程序，是由不同的团队来分别写入或者管理，并且它不像后台数据库那样频繁更新。你想要在SQL Server应用程序的存储过程中进行修改以充分利用新的功能。你还想要这个过程尽量温和，这样数据库和前端应用程序就都不会突然崩溃。
例如，你想要更新存储过程来使用SQL Server 2005的T-SQL中一些新的功能，例如TRY and CATCH函数，这个函数可以让复杂的错误追踪变得简单一点。你通常会拷贝现有的存储过程到一个新的并行的存储过程里面去，然后对它进行更新，使用新的功能，然后或者在经过修改的前端应用程序版本，或者查询分析器中测试两方面的行为。
当你很自信新的存储过程的行为是正确的，并且它也准备好用在产品中，你就可以无缝的替换它，例如通过修改两个存储过程的名字，或者通过代码的拷贝。我个人倾向于修改名字，因为这可以让你对原有的代码做个备份——像你的数据库中的其它东西一样，做个备份，以防出现不可预期的问题。
这是相对标准的技术，但是我曾见过的更有意思的一个问题涉及了可选参数传递：
CREATE PROCEDURE my_procedure
{其它的参数在这里},
@optionalparameter Boolean=FALSE
AS
If @optionalparameter=TRUE
Begin
{带有SQL Server 2005-特定命令的新版本的存储过程放在这里}
End
Else
Begin
{旧版本的存储过程放在这里}
End
还有另外一种有用的方式来选择性的测试代码。现有的前端对存储过程的呼叫不会使用可选参数，还会执行原来的代码。你可以在这里使用新的前端代码来测试存储过程，然后优雅地更新对现有存储过程的参考。因为参数是可选的，所有现有的对存储过程的呼叫(例如那些没有参数的呼叫)都会像以前一样准确地传递过去。
如果你不能添加新的存储过程，但是可以修改现有的存储过程的话，还有一种在这种限制下的好办法。当没有保留历史遗留代码的时候，你可以在存储过程中逐步淘汰IF。最后，在存储过程和你的前端代码中逐渐放弃可选参数。
中国风 2007-12-21
排序问题。。。好像是繁体版与简体版冲突
liangCK 2007-12-21
帮顶一下.
pt1314917 2007-12-21
貌似这个是排序规则吧。建数据库时候好象可以设置的``
改就不知道了。上次也是碰到过类似问题。还好只有一个存储过程用到这个。所以就手动在存储过程里面改了。。
改就不知道了。上次也是碰到过类似问题。还好只有一个存储过程用到这个。所以就手动在存储过程里面改了。。
