MS Access 2010 从 SQL 查询和主从关系创建表单
谁能给我提供创建基于 SQL 查询的表单的步骤。我已经使用向导编译了一个表单，并正在努力弄清楚如何基于 SQL 查询来完成它。以及使用我自己的设计来创建使用主细节关系的表单。
Can anyone provide me the steps to create a form that is based on an SQL Query. I have already compiled a form using the wizard and am working to figure out how to do it based on a SQL Query. As well as using my own design to create a form using a master detail relationship.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
SQL查询是什么意思？
您希望将表单绑定到记录集吗？如果是这样，请参阅http://support.microsoft.com/kb/281998。
您希望使用 SQL Server 视图作为记录源吗？您可以链接它： http://office.microsoft.com/en-us/access-help/import-or-link-to-sql-server-data-HA010200494.aspx
您希望将记录源设置为SQL 字符串？您可以手动或通过 VBA 执行此操作。
What do you mean by SQL query?
Do you wish to bind the form to a recordset? If so, see http://support.microsoft.com/kb/281998.
Do you wish to use an SQL Server view for the Record Source? You can link it: http://office.microsoft.com/en-us/access-help/import-or-link-to-sql-server-data-HA010200494.aspx
Do you wish to set the Record Source to an SQL string? You can do this manually or through VBA.
实际上，您可能错误地认为，当您使用一条记录构建主表单，然后想要在访问中编辑一些子详细记录时，您必须构建一个将两个表连接在一起的查询。我无法强调这是多么错误，而且大多数系统都不是这样工作的。
事实上，如果您要将主记录连接到子表，如果您有 10 个子记录，则主记录也会在该查询中重复 10 次，因此您想要主记录的 10 个复制品中的哪一个可以编辑吗？
因此，您当然可以自由地构建基于主表的查询，并且该查询不需要也没有任何要求加入任何子记录数据。一旦构建了此查询，您就可以随意使用向导，或者只需在设计模式下打开一个表单，然后根据此查询将字段拖放到表单中。完成后，您可以保存此主表单。现在，您可以基于子表构建新查询。然后，您现在再次基于此子表构建一个表单。完成此操作后，您可以将子表单放入主表单中，并且您将获得与向导完成的设置相同的设置。
因此，在这两种情况和两种方法中，绝对不需要构建连接其他表的 sql 查询。与基表相比，基于查询构建和建立表单确实没有特别的优势，甚至没有性能优势。对于编辑子表的子表单，直接将子表单基于子表或基于查询也没有特别的优势或性能问题。
因此，在访问模型以及编辑和维护父子数据或掌握详细信息时，您不必使用连接两个表的查询。因此，作为一般规则，表单将基于作为一个表的结果的查询。正如所指出的，将表单直接基于表格本身是可以接受的。
Actually you are probably mistaken in your belief that when you build a master form with one record, and then want to edit some child detail records in access that you have to build a query that joins the two tables together. I can't stress how wrong this is, and that's not the way most systems will work.
In fact if you are to join the master record to the child table, if you have 10 child records, the master record would also be repeated 10 times in that query, and which of the 10 reproductions of the master record would you thus want to be able to edit?
So you are most certainly free to build a query that's based on the master table, and that query does not need nor is there any requirement to join in any child record data. Once you build this query, then you are free to use the wizard or simply bring up a form in design mode and drop fields on into the form based on this query. When you've done that you can save this master form. You now can then build a new query based on the child table. And then again you now build a form based on this child table. Once you've done this, then you can drop the child form into the master form, and you have the same setup as to which the wizard has accomplished.
So in both cases and both approaches there's absolutely no requirement to build a sql query that joins in other tables. And there's really no particular advantage or even performance advantages to building and basing a form on a query as opposed to the base table. And for the child form that edits the child table, once again there's no particular advantage or performance issues by basing the child form on the child table directly, or basing it on a query.
So in access to model and edit and maintain parent to child data or master to details as you ask, you DO NOT have to use queries that join in the two tables. So as a general rule will base the form on an query that is the result of one table. As noted it's rather, and an acceptable to base the form directly on the table itself.