I have a form with two subforms. One of the subforms has another subform. I
need to set subform's subform's RecordSource (see subSubform11).

Form: frmPZ_Kniha
Subform1: frmPZ_DPH
subSubform11: frmPZ_DPHsum
Subform2: frmPZ_Denik

I have tried following but I didn't succeed:
Forms![frmPZ_Kniha]![frmPZ_DPH].Form![frmPZ_DPHsum].Form.RecordSource =
strRecordSource2
[frmPZ_DPH].Form![frmPZ_DPHsum].Form.RecordSource = strRecordSource2

In both cases I get the following error:
2455 Invalid reference to the property Form/Report

I need to set frmPZ_DPH's RecordSource as well
([frmPZ_DPH].Form.RecordSource = strRecordSource1). I'm trying to set record
sources in either Form_Open or Form_Load but I always get an error.

What am I doing wrong?

TIA

Vlado

On Fri, 25 May 2007 12:59:51 +0200, Vladimír Cvajniga <(E-Mail Removed)> wrote:

>I have a form with two subforms. One of the subforms has another subform. I
>need to set subform's subform's RecordSource (see subSubform11).

You refer to a subform like this:

Me.NameOfYourSubformCONTROL.Form.SomePropertyMethodEtc

Note the NameOfYourSubformCONTROL ... it may or may not be the name of the form being used as a subform, and this is
what trips most people up. Open your main form in design view, highlight the subform, then check the Properties dialog
.... this would tell you the name of the control.

To refer to subform on a subform:

Me.NameOfFirstSubformControl.Form.NameOfSecondSubformControl.Form.SomeProperty

This may help:
http://www.mvps.org/access/forms/frm0031.htm

Scott McDaniel
scott@takemeout_infotrakker.com
www.infotrakker.com

Thx for your respond, Scott. It really helps very much... but not in my case
since my code was OK. The form I open is a "dynamic" form and the problem is
that A2002 stores dynamic values (settings) with form. This is what really
drives me crazy nad for me it's just another A2002 bug... some would say
"issue". In this case it was AllowAdditions which should not be stored
(AllowAdditions was set to FALSE, in my original design it was set to
TRUE)...

Vlado

To Microsoft:
I don't want Access to store dynamic settings with forms! I WANT ACCESS TO
LEAVE MY DESIGN SETTINGS UNCHANGED (like in Visual Basic). It takes hours
and hours of searching what caused the problem, especially if the code has
been tested before. Do I have to reset all form's properties on Form_Close?
It sounds unbelievable... :-(

"Scott McDaniel" <scott@NoSpam_Infotrakker.com> píse v diskusním príspevku
news:(E-Mail Removed)...
> On Fri, 25 May 2007 12:59:51 +0200, Vladimír Cvajniga <(E-Mail Removed)>
> wrote:
>
>>I have a form with two subforms. One of the subforms has another subform.
>>I
>>need to set subform's subform's RecordSource (see subSubform11).
>
> You refer to a subform like this:
>
> Me.NameOfYourSubformCONTROL.Form.SomePropertyMethodEtc
>
> Note the NameOfYourSubformCONTROL ... it may or may not be the name of the
> form being used as a subform, and this is
> what trips most people up. Open your main form in design view, highlight
> the subform, then check the Properties dialog
> ... this would tell you the name of the control.
>
> To refer to subform on a subform:
>
> Me.NameOfFirstSubformControl.Form.NameOfSecondSubformControl.Form.SomeProperty
>
> This may help:
> http://www.mvps.org/access/forms/frm0031.htm
>
> Scott McDaniel
> scott@takemeout_infotrakker.com
> www.infotrakker.com

On Fri, 25 May 2007 14:47:51 +0200, Vladimír Cvajniga <(E-Mail Removed)> wrote:

>Thx for your respond, Scott. It really helps very much... but not in my case
>since my code was OK. The form I open is a "dynamic" form and the problem is
>that A2002 stores dynamic values (settings) with form.

Then I'm not sure what you're asking ... you asked how to set a subform/subform recordsource, and the method I describe
is the way to do it (and your code should work, assuming you've got everything named properly) regardless of whether
your form is dynamic or static. I'm not entirely sure what you mean by "dynamic", since by default pretty much every
form in a data-centric application would be dynamic (i.e. loaded with different values dependant on user selections,
filters, etc). If you mean something else by dynamic, perhaps you could clarify this for us.

Also, Access doesn't save changes made to form properties by default IF you don't open the form in design view. For
example, if I have a form named Form7, with AllowAdditions set to True, and I run this code from Form6:

Private Sub Command0_Click()
DoCmd.OpenForm "Form7"
Forms("Form7").AllowAdditions = False
End Sub

Setting a breakpoint at the first line, I then see that BEFORE the .AllowAdditions call is made, the value of that
property of Form7 is True ... Immediately after running the line, the value is now False (as expected) ... however, when
I open the Form7 in Design view, I see that Access has maintained the True value for the AllowAdditions property. If
your forms are NOT saving these values, then I'd suggest you may have some corruption issues.

This is what really
>drives me crazy nad for me it's just another A2002 bug... some would say
>"issue". In this case it was AllowAdditions which should not be stored
>(AllowAdditions was set to FALSE, in my original design it was set to
>TRUE)...


>
>Vlado
>
>To Microsoft:
>I don't want Access to store dynamic settings with forms! I WANT ACCESS TO
>LEAVE MY DESIGN SETTINGS UNCHANGED (like in Visual Basic). It takes hours
>and hours of searching what caused the problem, especially if the code has
>been tested before. Do I have to reset all form's properties on Form_Close?
>It sounds unbelievable... :-(

As seen above, Acess does NOT store dynamic settings IF you handle them correctly ...


>
>"Scott McDaniel" <scott@NoSpam_Infotrakker.com> píse v diskusním príspevku
>news:(E-Mail Removed)...
>> On Fri, 25 May 2007 12:59:51 +0200, Vladimír Cvajniga <(E-Mail Removed)>
>> wrote:
>>
>>>I have a form with two subforms. One of the subforms has another subform.
>>>I
>>>need to set subform's subform's RecordSource (see subSubform11).
>>
>> You refer to a subform like this:
>>
>> Me.NameOfYourSubformCONTROL.Form.SomePropertyMethodEtc
>>
>> Note the NameOfYourSubformCONTROL ... it may or may not be the name of the
>> form being used as a subform, and this is
>> what trips most people up. Open your main form in design view, highlight
>> the subform, then check the Properties dialog
>> ... this would tell you the name of the control.
>>
>> To refer to subform on a subform:
>>
>> Me.NameOfFirstSubformControl.Form.NameOfSecondSubformControl.Form.SomeProperty
>>
>> This may help:
>> http://www.mvps.org/access/forms/frm0031.htm
>>
>> Scott McDaniel
>> scott@takemeout_infotrakker.com
>> www.infotrakker.com

Scott McDaniel
scott@takemeout_infotrakker.com
www.infotrakker.com

Desing settings: Form.AllowAdditions = TRUE may change in code to FALSE.
With FALSE there were no records in main form and thus link field was
empty... and I got an error message.

It's very difficult to handle dynamic settings correctly if I don't know
HOW!!! There's NO information about how to handle code in debug and break.
To me it seems that if I need to change something in code I always have to
close all forms and reports before I make any change. Sometimes I simply
forget to close forms/reports before I make changes...

See my post in this newsgroup:
May 17th 2007 11:08
Access 2002 bug: "dynamic" forms problem - re-post plus more...
http://groups.google.co.uk/group/microsoft.public.access/browse_thread/thread/73989b3f9ada1bcf/8bfea619ac606fa8?lnk=st&q=(May+5th+2007)+about+a+fortnight+so+I+try+it+here...&rnum=1&hl=en#8bfea619ac606fa8


TIA

Vlado

"Scott McDaniel" <scott@NoSpam_Infotrakker.com> píse v diskusním príspevku
news:(E-Mail Removed)...
> On Fri, 25 May 2007 14:47:51 +0200, Vladimír Cvajniga <(E-Mail Removed)>
> wrote:
>
>>Thx for your respond, Scott. It really helps very much... but not in my
>>case
>>since my code was OK. The form I open is a "dynamic" form and the problem
>>is
>>that A2002 stores dynamic values (settings) with form.
>
> Then I'm not sure what you're asking ... you asked how to set a
> subform/subform recordsource, and the method I describe
> is the way to do it (and your code should work, assuming you've got
> everything named properly) regardless of whether
> your form is dynamic or static. I'm not entirely sure what you mean by
> "dynamic", since by default pretty much every
> form in a data-centric application would be dynamic (i.e. loaded with
> different values dependant on user selections,
> filters, etc). If you mean something else by dynamic, perhaps you could
> clarify this for us.
>
> Also, Access doesn't save changes made to form properties by default IF
> you don't open the form in design view. For
> example, if I have a form named Form7, with AllowAdditions set to True,
> and I run this code from Form6:
>
> Private Sub Command0_Click()
> DoCmd.OpenForm "Form7"
> Forms("Form7").AllowAdditions = False
> End Sub
>
> Setting a breakpoint at the first line, I then see that BEFORE the
> .AllowAdditions call is made, the value of that
> property of Form7 is True ... Immediately after running the line, the
> value is now False (as expected) ... however, when
> I open the Form7 in Design view, I see that Access has maintained the True
> value for the AllowAdditions property. If
> your forms are NOT saving these values, then I'd suggest you may have some
> corruption issues.
>
> This is what really
>>drives me crazy nad for me it's just another A2002 bug... some would say
>>"issue". In this case it was AllowAdditions which should not be stored
>>(AllowAdditions was set to FALSE, in my original design it was set to
>>TRUE)...
>
>
>>
>>Vlado
>>
>>To Microsoft:
>>I don't want Access to store dynamic settings with forms! I WANT ACCESS TO
>>LEAVE MY DESIGN SETTINGS UNCHANGED (like in Visual Basic). It takes hours
>>and hours of searching what caused the problem, especially if the code has
>>been tested before. Do I have to reset all form's properties on
>>Form_Close?
>>It sounds unbelievable... :-(
>
> As seen above, Acess does NOT store dynamic settings IF you handle them
> correctly ...
>
>
>>
>>"Scott McDaniel" <scott@NoSpam_Infotrakker.com> píse v diskusním príspevku
>>news:(E-Mail Removed)...
>>> On Fri, 25 May 2007 12:59:51 +0200, Vladimír Cvajniga
>>> <(E-Mail Removed)>
>>> wrote:
>>>
>>>>I have a form with two subforms. One of the subforms has another
>>>>subform.
>>>>I
>>>>need to set subform's subform's RecordSource (see subSubform11).
>>>
>>> You refer to a subform like this:
>>>
>>> Me.NameOfYourSubformCONTROL.Form.SomePropertyMethodEtc
>>>
>>> Note the NameOfYourSubformCONTROL ... it may or may not be the name of
>>> the
>>> form being used as a subform, and this is
>>> what trips most people up. Open your main form in design view, highlight
>>> the subform, then check the Properties dialog
>>> ... this would tell you the name of the control.
>>>
>>> To refer to subform on a subform:
>>>
>>> Me.NameOfFirstSubformControl.Form.NameOfSecondSubformControl.Form.SomeProperty
>>>
>>> This may help:
>>> http://www.mvps.org/access/forms/frm0031.htm
>>>
>>> Scott McDaniel
>>> scott@takemeout_infotrakker.com
>>> www.infotrakker.com
>
> Scott McDaniel
> scott@takemeout_infotrakker.com
> www.infotrakker.com

On Fri, 25 May 2007 15:50:51 +0200, Vladimír Cvajniga <(E-Mail Removed)> wrote:

>Desing settings: Form.AllowAdditions = TRUE may change in code to FALSE.
>With FALSE there were no records in main form and thus link field was
>empty... and I got an error message.

Still not really following, but in the specific case you mention, why not check for an empty recordset first, then
set/unset the various options (or check whatever recordset/database/form property you need, then take action). Access is
databound, and it does make certain assumptions. If you don't want to use the databound properties of Access, then build
an unbound application, or move to VB

> It's very difficult to handle dynamic settings correctly if I don't know
>HOW!!! There's NO information about how to handle code in debug and break.
>To me it seems that if I need to change something in code I always have to
>close all forms and reports before I make any change. Sometimes I simply
>forget to close forms/reports before I make changes...

Hanlding code in Debug/Break is pretty simple: You should never make code changes in Debug/Break mode. While you don't
need to close all forms/reports to make changes, you should definitely stop the debugger, open the object in Design
mode, then make the changes.

I read your newsgroup posting at the link below and refer you to Larry's response to you: Access isn't VB, and is very,
very different in many ways. To me, we (as developers) have strecthed the limits of Access beyond what the original
developers imagined it to be (a desktop database design system suitable for small workgroups). Now, we have people
developing commerically available applications in Access and they expect it to behave like VB or C/C++ ... and it won't.

Don't get me wrong, I would really like for Access to behave more like VB, but that's just not going to happen ... you
simply can't make changes to Access objects in Break/Debug mode, and that's a known fact (and it's not a "bug" just
because you think it should behave that way) and has been that way since (at least) Access 2000.

Scott McDaniel
scott@takemeout_infotrakker.com
www.infotrakker.com

Still not really following, but in the specific case you mention, why not
check for an empty recordset first...
>>> Well, there are three various modes:

1) add mode
default (in original design Form.AllowAdditions is set to TRUE)

2) edit mode
AllowAdditions = FALSE

3) read only
AllowAdditions = FALSE

The problem occured when I accidentaly saved the form in form view. It's
very easy, even for end-user: just press CtrlS. Then (if AllowDeletions =
FALSE) I couldn't open the form in add mode. I didn't expect that Access
would save dynamic settings. IMHO, CtlrS is very dangerous for any dynamic
form so that I'm going to forbide this shortcut... :-/
--------------------
Debug/Break
>>> I'd appreciate that code window was locked in Debug/Break (like in VB).
>>> It is not very difficult to add this feature to new version of Access -
>>> especially if editing in Debug/Break leads to database corruption.

Thank you very much for your time, Scott, you are very helpful. I appreciate
it! :-)

Vlado

"Scott McDaniel" <scott@NoSpam_Infotrakker.com> píse v diskusním príspevku
news:(E-Mail Removed)...
> On Fri, 25 May 2007 15:50:51 +0200, Vladimír Cvajniga <(E-Mail Removed)>
> wrote:
>
>>Desing settings: Form.AllowAdditions = TRUE may change in code to FALSE.
>>With FALSE there were no records in main form and thus link field was
>>empty... and I got an error message.
>
> Still not really following, but in the specific case you mention, why not
> check for an empty recordset first, then
> set/unset the various options (or check whatever recordset/database/form
> property you need, then take action). Access is
> databound, and it does make certain assumptions. If you don't want to use
> the databound properties of Access, then build
> an unbound application, or move to VB
>
>> It's very difficult to handle dynamic settings correctly if I don't know
>>HOW!!! There's NO information about how to handle code in debug and break.
>>To me it seems that if I need to change something in code I always have to
>>close all forms and reports before I make any change. Sometimes I simply
>>forget to close forms/reports before I make changes...
>
> Hanlding code in Debug/Break is pretty simple: You should never make code
> changes in Debug/Break mode. While you don't
> need to close all forms/reports to make changes, you should definitely
> stop the debugger, open the object in Design
> mode, then make the changes.
>
> I read your newsgroup posting at the link below and refer you to Larry's
> response to you: Access isn't VB, and is very,
> very different in many ways. To me, we (as developers) have strecthed the
> limits of Access beyond what the original
> developers imagined it to be (a desktop database design system suitable
> for small workgroups). Now, we have people
> developing commerically available applications in Access and they expect
> it to behave like VB or C/C++ ... and it won't.
>
> Don't get me wrong, I would really like for Access to behave more like VB,
> but that's just not going to happen ... you
> simply can't make changes to Access objects in Break/Debug mode, and
> that's a known fact (and it's not a "bug" just
> because you think it should behave that way) and has been that way since
> (at least) Access 2000.
>
> Scott McDaniel
> scott@takemeout_infotrakker.com
> www.infotrakker.com