views:

1232

answers:

2

I've struggling with this problem on my own, then with some help, then search about it; but I haven't had any luck. So I decided to ask.

I have two forms in Access 2007 lets call them MainForm and EntryForm.
MainForm has a subform and a button. The button opens the EntryForm in Add Mode. What I want to do is when the EntryForm saves the new record it would update (requery) the subform in MainForm.

I've try this setup code

Private Sub cmdSaveAndClose_Click()
    DoCmd.Save

    'requery list
    Forms![MainForm]![subformName].Requery

    '' I've also tried these
    'Forms![MainForm]![subformName].Form.Requery
    'Forms.("MainForm").[subformName].Requery
    'Forms.("MainForm").[subformName].Form.Requery


    DoCmd.Close
End Sub

None of these attempts seem to work. Is there a way to make this requery? Thanks for the help in advance.

A: 

You must use the name of the subform control, not the name of the subform, though these are often the same:

 Forms![MainForm]![subform control name Name].Form.Requery

Or, if you are on the main form:

 Me.[subform control name Name].Form.Requery

More Info: http://www.mvps.org/access/forms/frm0031.htm

Remou
The later syntax will perform better. (Bang operators cause an implicit type conversion.)
Oorang
Not if you are not running from the form that contains the subform it won't :)
Remou
I've tried the first, like this `Forms![MainForm]![subformControl].Form.Requery` and it doesn't requery the subform. TThe code is tied to the other form button. Unless there is a way to requery the subform from the parent form when the other form is closed, I can't try the later syntax.
Tony L.
Can you ensure that id is selecting the subform by say, setting focus to a field? This should eliminate the possibility that there is some sort of spelling error.
Remou
The . operator depends on implicitly-created properties over which you have no control (that's how Me.ControlName becomes subject to compile-time checking, because there's a hidden property wrapper around it). This causes a marginal increase in the tendency to VBA code corruption. Some people find the compile-time checking and the better Intellisense worth that risk. I don't -- I always use the ! operator. There is no performance difference that could possibly make a real-world difference.
David-W-Fenton
@Oorang: citation on the implicit type conversion assertion?
David-W-Fenton
+1  A: 

Just a comment on the method of accomplishing this:

You're making your EntryForm permanently tied to the form you're calling it from. I think it's better to not have forms tied to context like that. I'd remove the requery from the Save/Close routine and instead open the EntryForm modally, using the acDialog switch:

  DoCmd.OpenForm "EntryForm", , ,"[ID]=" & Me!SubForm.Form!ID, , acDialog
  Me!SubForm.Form.Requery

That way, EntryForm is not tied down to use in one context. The alternative is to complicate EntryForm with something that is knowledgable of which form opened it and what needs to requeried. I think it's better to keep that kind of thing as close to the context in which it's used, and keep the called form's code as simple as possible.

Perhaps a principle here is that any time you are requerying a form using the Forms collection from another form, it's a good indication something's not right about your architecture -- that should happen seldom, in my opinion.

David-W-Fenton
That's great it worked with the acDialog. At first I was trying to do all of these from the main form, but it didn't occur to me to use the acDialog, but I guess my brain was fried by the end of these week. Thanks.
Tony L.