我有一个Access 2010数据库,它链接到SQL Azure后端(是的,我知道这不是理想的,而且它正逐渐被淘汰)。在后端,我有一个存储过程,我想在每次加载新记录时使用它来填充只读子表单。我试图通过在VBA中生成记录集,然后设置子表单的RecordSet
属性来做到这一点。它确实有效,但有一个令人讨厌的副作用。
当我设置RecordSet
属性时,它似乎也设置了子窗体的RecordSource
属性。 RecordSource是Access无法解析的东西,因为它意味着对后端的调用。如果我尝试使用DAO passthrough查询来生成记录集,则RecordSource看起来像:
EXEC dbo.GetDuplicateAddressesByManufacturer N'...', N'...', N'...'
如果我尝试使用ADO命令生成记录集,它看起来像:
{ call dbo.GetDuplicateAddressesByManufacturer ?, ?, ? }
当我尝试移动到下一条记录时,Access会抛出一个错误,因为它首先尝试为子窗体加载一条新记录,并且它无法打开它所看到的子窗体的RecordSource。如果我正在尝试DAO路由,它会告诉我“无效的SQL语句”,如果我使用的是ADO,它会告诉我“数据提供程序无法初始化。”
任何人都知道如何解决这个问题?是否有办法设置RecordSet属性而不设置RecordSource?我可以发誓之前我已经做过了,但也许我从来没有注意到RecordSource也被设置了。
如果失败了,有没有办法在Form_Current事件之前插入一些代码来删除子窗体的RecordSource?我每次用来设置RecordSet的代码都很好用 - 问题是我的代码工作之前引发的错误。一旦我解除了错误消息,一切正常,但显然我不希望用户每次更改记录时都会收到错误消息。
如果所有其他方法都失败了,我想我总是可以使用查询来填充本地临时表,但是每次有人移动到新记录时都会花费很多开销。
答案 0 :(得分:0)
为什么要使用存储过程呢?只需将子表单链接到表格,然后设置链接主/子设置。您只需下拉所需的记录。
如果子表单是一个包含多个表的复杂查询,那么您当然希望数据连接等发生在服务器端,而AGAIN只需创建一个视图并再次将子表单源设置为该视图(并再次设置链接主数据) / child设置将为您完成所有脏工作。)
并且没有理由不能创建传递查询并且SIMPLE将其分配给表单recordSource。
您在查询中放置的“垃圾”并不重要,包括RAW T-SQL。
虽然你可以用这个传递思想加载DAO reocrdset,但你真的不需要。我想你有一些快乐的理由,至少如果你必须的话,那么recordSoruce就会成为传递的名称,而不是原始的T-SQL。
但是,真的,只是转储所有记录集垃圾,然后去:
Me.MySubForm.Form.RecordSource = "my pass though query".
因此上面只有一行。
你做所有这些手台以提高性能然后在一天结束时为什么你的主要形式允许导航?您应该构建一个搜索屏幕,显示结果,让用户选择一行,然后启动主窗体以编辑/显示ONE记录以及子表单数据。
当他们关闭时,他们又回来寻找下一个客户等。这种方法也因此解决了你的混乱导航问题。这也是网络和大多数软件以这种方式工作的原因(它减少了带宽问题)。
但是,如果你必须有导航,并且由于某种原因不能使用视图,并且不能让Access使用链接主/子设置来做你的脏工作?
然后在表单on-current事件中,您可以修改pass-though并简单地将其重新分配给子表单。
例如:
With CurrentDb.QueryDefs("qPass")
.SQL = "select * from FaxBook3 where id = 3"
End With
'
Me.RecordSource = "qpass"
现在我如何在pass-though查询中使用RAW T-SQL,然后简单地将pass-though分配给表单recordsource(在你的情况下,你指定给子表单。
Me.MySubForm.Form.RecordSource = above
没有理由说上面的.SQL不能成为你的存储过程
.SQL = "Exec your-storedProcedure " & strVbaStringParmater
再次分配表单(或子表单)recordSource。
所以你真的不需要在代码中创建一些reocrdset,它不会让你获得任何性能提升,但会导致你编写更多的代码并遇到你在帖子中概述的问题。