sql server - 框架 4 - IIS 7 从数据库到页面的奇怪排序
已解决 - 请参阅下面的解释末尾
在调用方法中从数据库读取结果集时，我遇到了奇怪的行为。行的排序与数据库应返回的排序不同。
我的农场：
- 数据库服务器：WinServer 2008 64 位上的 SQL Server 2008
- Web 服务器：几个负载平衡的 WinServer 2008 64 位运行 IIS 7
该应用程序在 v4.0 应用程序池上运行，设置为启用 32 位应用程序
以下是问题的描述：
- 调用存储过程，返回按特定列排序的结果集
- 我可以通过探查器看到对 SP 的调用，如果我运行该语句，我会看到正确的排序
- 调用页面获取结果，并在 SP 执行后立即记录行，然后再进一步详细说明
- 结果的顺序完全不同（我什至无法理解它们是否以任何方式排序）
有关存储过程的一些详细信息：
- 它由使用 SqlDatAdapter 的代码调用
- 它还有一个可以正确读取的输出值（行数）
- 要使用哪个排序字段作为参数传递 - 利用临时表来收集数据并执行所需的排序
知道我可以检查什么吗？相同的代码和相同的数据库在测试环境（32 位且未负载平衡）中正常工作。
已解决 - 这是存储过程逻辑中的问题；在最后一个选择中，我对一个列进行了内部联接，结果排序（但仅在生产数据库中）在该字段上，降序排列，而不是在所需的列上。修改了逻辑，现在一切正常了。我仍然需要了解这种行为的真正原因仅在一个数据库上而不是在另一个数据库上。也许一些索引...
SOLVED - look below at the end of the explanation
I am experiencing a strange behavior when reading a resultset from database in a calling method. The sort of the rows is different from what the database should return.
My farm:
- database server: sql server 2008 on a WinServer 2008 64 bit
- web server: a couple of load balanced WinServer 2008 64 bit running IIS 7
The application runs on a v4.0 app pool, set to enable 32bit applications
Here's a description of the problem:
- a stored procedure is called, that returns a resultset sorted on a particular column
- I can see thru profiler the call to the SP, if I run the statement I see correct sorting
- the calling page gets the results, and before any further elaboration logs the rows immediately after the SP execution
- the results are in a completely different order (I cannot even understand if they are sorted in any way)
Some details on the Stored Procedure:
- it is called by code using a SqlDatAdapter
- it has also an output value (a count of the rows) that is read correctly
- which sort field is to be used is passed as a parameter
- makes use of temp tables to collect data and perform the desired sort
Any idea on what I could check? Same code and same database work correctly in a test environment, 32 bit and not load balanced.
SOLVED - it was a problem in the stored procedure logic; in the last select I had an inner join towards a column, and the resulting sort (but only in the production db) was on that field, descending, instead that on the desired column. Modified the logic, now everything works. I still have to understand where is the real reason of this behavior only on one database and not against the other. Maybe some indexes...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论