Microsoft SQL Server 本机客户端是否支持 IDBAsynchNotify？
我正在编写一些 OLE DB 代码，这些代码通过 ICommand::Execute 在 MS SQL Server 上运行查询。我在执行之前通过在命令上设置 DBPROPVAL_ASYNCH_INITIALIZE 属性将此代码转换为异步操作。
我更愿意注册一个 IDBAsynchNotify 接收器，以便我的代码可以收到事件通知，而不是通过 ISSAsynchStatus 进行轮询或阻止。
ICommand 的 文档： :Execute 不会将 IConnectionPointContainer 显示为可接受的 riid 参数，但同一文档在讨论 DB_S_ASYNCHRONOUS 返回代码时建议可以请求一个 IConnectionPointContainer 接口，我可以用它来注册我的事件接收器。
当我调用 ICommand::Execute 并将 IID_IConnectionPointContainer 作为 riid 参数传递时，我收到 E_NOINTERFACE 错误。我还尝试在 Execute 之前设置 DBPROP_IConnectionPointContainer 属性，但收到了相同的结果。
如果必须的话，我会使用 ISSAsynchStatus，但我更愿意使用 IDBAsynchNotify。是否可以？
I'm working on some OLE DB code that runs queries on MS SQL Server via ICommand::Execute. I'm converting this code to operate asynchronously by setting the DBPROPVAL_ASYNCH_INITIALIZE property on the command before executing.
I'd prefer to register a IDBAsynchNotify sink so that my code can be notified of events, as opposed to polling or blocking via ISSAsynchStatus.
The documentation for ICommand::Execute does not show IConnectionPointContainer as an acceptable riid parameter, but the same document, when discussing the DB_S_ASYNCHRONOUS return code, suggests that it is possible to request an IConnectionPointContainer interface that I could use to register my event sink.
When I call ICommand::Execute, passing IID_IConnectionPointContainer as the riid parameter, I receive the E_NOINTERFACE error. I also tried setting the DBPROP_IConnectionPointContainer property before Execute but I received the same results.
If I have to, I'll use ISSAsynchStatus, but I'd much rather use IDBAsynchNotify. Is it possible?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
请参阅 SQL Native Client 的执行异步操作 OLE Db 细节，包括示例。该链接表示唯一可接受的 RIID 是 IID_IDBAsynchStatus 和 IID_ISSAsynchStatus，因此我的理解是编程模型是基于池的，而不是基于通知的。
See Performing Asynchronous Operations for SQL Native Client OLE Db specifics, including examples. The link says the only acceptable RIIDs are IID_IDBAsynchStatus and IID_ISSAsynchStatus, so my understanding that is that the programming model is pool based, not notification based.
根据 这篇 SQL Server Native Client 博客文章，“异步通知编程模型”是本机客户端请求的第五个最重要的功能。我想这回答了问题。希望 sqlncli 团队能够尽快解决这个问题。我很容易对民意调查感到恼火。
According to the response on this SQL Server Native Client blog post, "asynchronous notification programming model" was the fifth most important feature that was requested for the native client. I guess that answers the question. Hopefully the sqlncli team will address this sooner rather than later. I am easily annoyed by polling.