数据表中的 MS-Access 未绑定组合框?

发布于 2024-09-15 23:59:00 字数 443 浏览 6 评论 0原文

在 ms-access 2007 中,我试图为表格制作一个表单。该表有来自 2 个父表的外键。所以我想我应该对这些字段进行查找。但我无法为每个父表创建单个查找,因为它们是复合键。

我决定创建一个查询,其中每个父表和子表的每个组合键都有一个额外的字段。这对于使用未绑定的 ComboBox 的普通表单工作得很好...但是未绑定的 ComboBox 在数据表子表单中不起作用。当我对子表单代码中的组合框进行更改时,它们也会应用于同一列中的所有其他组合框。

我的问题:

  • 有没有办法更改单个未绑定 ComboBox 的值?

  • 除了 ComboBox 或 DataSheet 子窗体之外,我是否应该使用其他控件?

  • 这种情况的正常解决方法是什么?

我无法绑定组合框,因为正如我所说,查询中的字段是计算/表达式的。

In ms-access 2007, i'm trying to make a form for a table. this table has foreign keys from 2 parent tables. so i thought i would make these fields a lookup. but i couldn't create a single lookup for each parent table because they are composite keys.

I decided to create a query in which for each of these parent tables and the child table with an extra field for each composite key. this works fine with a normal form using an unbound ComboBox... but the unbound ComboBox does not work in a DataSheet Subform. when i make changes to a ComboBox in the Subform code, they are applied to all the other ComboBoxes in the same column as well.

My questions:

  • is there a way to change the values of the individual unbound ComboBox?

  • is there a different control i should be using other than the ComboBox or the DataSheet Subform?

  • what is the normal work around for this situation?

I cannot bind the ComboBox's because the field from the query is calculated/an-expression as I said.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

剑心龙吟 2024-09-22 23:59:00

我自己遇到了这个问题的一种形式,所以为了子孙后代:

虽然一般来说,建议“在这种情况下不要使用连续的表单/数据表”是最好的建议......可以解决这个问题。

但是,Access 不允许您更新数据表上单个控件的值。在这种情况下可以使用临时表,当用作记录源时,它可以成为这些控件的值。但是,每次需要更改计算时,您都需要重新填充表,并重新查询控件(重新查询整个表单也应该有效)。此外,如果您在控件上启用编辑,则必须在每个控件上编写一些 VBA 来处理更新事件(更新之前),并运行您自己的查询来更新源表,而不仅仅是临时表。这样做也许很烦人,但很有效。

还有另一种可能性,也可能有效,但我自己还没有尝试过做类似的事情。组合框的行源可能非常复杂,因此您可能根本不需要使用 VBA 更新组合框。行源可以使用语法 Me.Form!controlName 或 Forms!FormName!ControlName 依赖于其他控件(例如另一个组合框),这将允许您形成组合键。当然,您也可以从具有行源的查询中进行选择。更有趣的是,只要表单打开,查询就可以引用表单上的控件,并且如果需要,您应该能够安全地使用 VBA 对其进行修改。

在这两者之间,您应该能够强制访问,踢和尖叫,显示您想要的任何数据,甚至在数据表上,并允许用户更改该数据(但前提是您愿意),并且使用 BeforeUpdate 事件,将修改后的数据拖回其来源的表中。

I ran across a form of this problem myself, so for the sake of posterity:

While generally, the advice "Don't use continuous forms/datasheets in this situtation" is the best advice...It is possible to work around this.

However, access will not let you update the value of a single control on a datasheet. What can be used instead in this case is a temporary table, which can, when used as a recordsource, become the values of those controls. You will need to repopulate the table, and requery the controls (requerying the entire form should work as well) every time the calculation needs to change, however. Furthermore, should you enable editing on the controls, you will have to write some VBA on each control to handle the update event (Before Update), and run your own query to update the source tables, not merely the temporary table. Annoying to do perhaps, but effective.

There is another possibillity, which may also work, but I haven't tried to do something quite like this myself. The rowsource of a combobox can be very complex, so it is probable that you do not need to update the comboboxes with VBA at all. The rowsource can depend on other controls (such as another combobox) using the syntax Me.Form!controlName or Forms!FormName!ControlName, which will allow you to form the composite key. Of course, you can also select from queries with a rowsource. What is more interesting is that queries can reference controls on your form, provided the form is open, and you should safely be able to modify that with VBA should you have to.

Between the two of these, you should be able to force access, kicking and screaming, to display any data you wish, even on a datasheet, and to allow the user to change that data (but only if you want it to), and using the BeforeUpdate event, drag modified data back to whatever table it came from.

維他命╮ 2024-09-22 23:59:00

在需要有条件更改组合框的情况下,连续表单和数据表不适用于编辑。问题是,如果您使用 OnCurrent 事件设置组合框的 Rowsource,则该行可以正常使用,但随后会隐藏其他行的存储值。

解决方案是在这种情况下永远不要使用连续表单/数据表来编辑数据(事实上,我几乎从未使用它们进行编辑)。您可以创建两个子窗体,一个用作列表的连续/数据表子窗体,以及一个显示一条记录的详细信息子窗体。使列表子表单不可编辑,而详细信息子表单可编辑。您可以使用详细信息子表单控件的“链接子表单”/“链接主表单”属性链接这两个表单,并将其设置为列表子表单的 PK。

如果您的列表子表单是 Me!List,详细信息是 Me!Form,并且 PK 字段是 MyID,则详细信息子表单的链接属性将为:

  Master: Me!List.Form!MyID
  Child:  MyID

当您移动到列表表单中的其他记录时,它将自动加载以子形式。对先前显示的详细信息的任何编辑都将在记录出发前保存。

Continuous forms and datasheets do not work well for editing in situations where combo boxes need to be changed conditionally. The problem is that if you use the OnCurrent event to set the Rowsource of the combo box, it will be OK for that row, but will then hide the stored values for other rows.

The solution is to never use continuous forms/datasheets for editing data when this is the case (I hardly ever use them for editing, in fact). You can create two subforms, a continuous/datasheet subform that functions as a list, and a detail subform, that displays one record. Make the list subform uneditable, and the detail subform editable. You can link the two of them by using the Link Child/Link Master property of the detail subform control, and set it to the PK of the list subform.

If your list subform is Me!List and your detail is Me!Form, and the PK field is MyID, your link properties for the detail subform would be:

  Master: Me!List.Form!MyID
  Child:  MyID

When you move to a different record in the list form, it will be automatically loaded in the child form. Any edits to the previously displayed detail will be saved before record departure.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文