从 .NET 调用 SQL Server 2008 中的存储过程时，结果排序不正确
我们有一个存储过程，它使用 ORDER BY 中的参数和 CASE 按不同列对结果进行排序。如果我们从 SSMS 执行存储过程，则无论我们使用哪个版本的 SQL Server（2005 或 2008），记录始终根据参数排序。如果我们从应用程序中使用完全相同的参数值调用它，它只会在 SQL Server 2005 中正确排序。我单步执行 SQLDataReader，它在 2008 中以错误的顺序获取记录。
我也在 .NET 2.0 中尝试过确保它与 .NET Framework 版本 4.0 没有关系，我得到了相同的结果。
据我所知，除了 SQL Server 版本之外，这些服务器之间的唯一区别是使用 SQL 2008 的服务器是多处理器。
造成这种情况的原因是什么？任何帮助将不胜感激。
We have a stored procedure that uses a parameter and a CASE in ORDER BY to sort the results by different columns. If we execute the stored procedure from SSMS, the records are always sorted according to the parameter no matter which version of SQL Server we use (2005 or 2008). If we call it from the app with the exact same parameter values, it only does the ordering correctly with SQL Server 2005. I stepped through the SQLDataReader and it's getting the records in the wrong order with 2008.
I tried in .NET 2.0 as well to be sure it didn't have something to do with the .NET framework version being 4.0 and I got the same results.
The only difference between these servers that I'm aware of, besides SQL Server version, is the server with SQL 2008 is a multi-processor.
What could be the cause for this? Any help will be greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我将在这里冒险假设您的 CASE 语句正在检查参数中的 NULL 值。发送 .NET
NULL值可能无法与使用默认设置的 SQLNULL值配合良好。例如，如果您的参数是字符串，并且您使用集成的
SQLDataProvider，则有一个设置会自动将NULL字符串替换为 空白 字符串。我将通过使用 sproc
SELECT参数来验证您的 .NET 是否确实发送了您认为是的参数。事实上，如果您依赖
NULL参数，我会在您的 .NET 中处理验证，然后不将参数发送到存储过程。这是确保参数实际上为 NULL 的一种非常简单的方法I'm going to go out on a limb here and assume that your
CASEstatement is checking forNULLvalues in the parameter. Sending .NETNULLvalues may not play nice with SQLNULLvalues using default settings.For example, if your parameter is a string, and you're using the integrated
SQLDataProviderthen there is a setting which automatically replacesNULLstrings with blank strings.I would verify that your .NET is actually sending the parameter you think it is by having the sproc
SELECTyour parameter.If you are, in fact, depending on a
NULLparameter, I would handle the validation in your .NET and then just not send the parameter to the sproc. This is a pretty fool-proof way to make sure the parameter is actuallyNULL当数据库是 SQL Server 2005 并在 2008 下运行时，我看到这种奇怪的错误。
确保兼容性级别与服务器版本匹配。
一张图片相当于 1000 个字：
在这种情况下，数据库不处于建议的兼容性级别。
小心！！！一旦更改兼容性级别，您可能无法撤消，因此请做好备份！！！
注意！！！一旦更改兼容性级别，您可能无法撤消，因此请做好备份！！！
注意！！！一旦更改兼容级别，您可能无法撤消，因此请做好备份！！！
I saw this kind of strange errors when the database is a SQL Server 2005 and running under 2008.
Make sure the compatibility level matches the server version.
A picture worth a 1000 words:
In this case, the database is not in the recommended compatibility level.
CAUTION!!! Once you change the compatibility level, you might not be able to undo it, so please make a backup!!!
CAUTION!!! Once you change the compatibility level, you might not be able to undo it, so please make a backup!!!
CAUTION!!! Once you change the compatibility level, you might not be able to undo it, so please make a backup!!!