SQL Server / ODBC 可滚动结果集性能
我有一个通过 ODBC 连接到 SQL Server 数据库的应用程序，并通过 Web 界面提供查询功能。为了将数据库映射到我们的 Web 框架上，我使用了可滚动结果集。应用程序的其余大部分都使用只进游标。
我有一个包含大量行的订单表和一个查询：
SELECT * FROM order
如果我使用自己的命令行程序运行它，它会立即开始返回数据。如果我只获取 25 行，查询运行得非常快。如果我在 Web 屏幕上运行它，查询会在 30 秒后超时，并且不会返回任何数据。
除了游标类型之外，这两种方法都会经历相同的调用顺序。在命令行程序中，我使用SQLSetStmtAttr将SQL_ATTR_CURSOR_TYPE设置为SQL_CURSOR_FORWARD_ONLY，而在网页版本中，我使用SQL_CURSOR_DYNAMIC代码>.
我使用调试器来找出延迟在哪里，我发现 SQLExecute 调用需要大约 50 秒，并且游标设置为动态。有关信息，我之前使用过 SQL_CURSOR_STATIC，而 SQL_CURSOR_DYNAMIC 是我第一次尝试解决该问题。
有什么方法可以通过 ODBC 在 SQL Server 中获取高性能的可滚动结果集吗？
I've got an application connecting to a SQL Server database via ODBC, and providing query functionality through a Web interface. In order to map the database onto our web framework, I am using a scrollable result set. Most of the rest of the application uses a forward-only cursor.
I've got an order table with a huge number of rows, and a query:
SELECT * FROM order
If I run this with my own command line program, it immediately starts returning data. If I only fetch 25 rows, the query runs very quickly. If I run it on the web screens, the query times out after 30 seconds, without returning any data.
Both methods go through the same sequence of calls, except for the cursor type. In the command line program, I use SQLSetStmtAttr to set SQL_ATTR_CURSOR_TYPE to SQL_CURSOR_FORWARD_ONLY, while in the web version, I use SQL_CURSOR_DYNAMIC.
I've gone in with the debugger to find out where the delay is, and what I've seen is the SQLExecute call takes around 50 seconds with the cursor set to dynamic. For info, I was using SQL_CURSOR_STATIC before, and SQL_CURSOR_DYNAMIC is my first attempt to fix the problem.
Is there any way to get a performant scrollable result set in SQL Server via ODBC?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
无论您使用什么 API，可滚动游标在 sql server 上都是严重的禁忌 - 而 ODBC 使它们变得更加重要。不惜一切代价绕过他们。
Scrollable cursors are seriously a no no no on sql server regardless what API you use - and ODBC makes them ahrder. Get around them pretty much at any cost.