Annoying parameter requests

[ragtopcaddy via AccessMonster.com]

I have a subform whose recordsource is a query that refers to controls on its
parent form.
If I open this subform from design view, it requests the parameters (values
in controls) in the parent form. This is to be expected, as I'm opening the
subform by itself and the controls referred to are not present.

When I open the parent form with the subform, I don't get the parameter
requests.

However, the parent form is itself a subform. When I open the parent of the
parent form, I get the same parameter requests that I got when I attempted to
open the subform by itself.

Here's the SQL:

SELECT "PE Factors" AS Source,
IIf(IsNull([Forms]![sfrmPortfolioTrades]![txtStart]),
[Forms]![sfrmPortfolioTrades]![DoV],
[Forms]![sfrmPortfolioTrades]![txtStart]) AS dtStart,
Format([VarFactor],"0.000000") AS VarFctr,
Format([06],"0.000000") AS TB01,
Format([06],"0.000000") AS TB02,
Format([06],"0.000000") AS TB03
FROM tblPEFactorsPF;

The parameters requested are "txtStart" and "DOV"

Thanks,

Bill R

--
Bill Reed

"If you can't laugh at yourself, laugh at somebody else"

Message posted via AccessMonster.com

 

[Rick Brandt]

I have a subform whose recordsource is a query that refers to
controls on its parent form.
If I open this subform from design view, it requests the parameters
(values in controls) in the parent form. This is to be expected, as
I'm opening the subform by itself and the controls referred to are
not present.

When I open the parent form with the subform, I don't get the
parameter requests.

However, the parent form is itself a subform. When I open the parent
of the parent form, I get the same parameter requests that I got when
I attempted to open the subform by itself.

Here's the SQL:

SELECT "PE Factors" AS Source,
IIf(IsNull([Forms]![sfrmPortfolioTrades]![txtStart]),
[Forms]![sfrmPortfolioTrades]![DoV],
[Forms]![sfrmPortfolioTrades]![txtStart]) AS dtStart,
Format([VarFactor],"0.000000") AS VarFctr,
Format([06],"0.000000") AS TB01,
Format([06],"0.000000") AS TB02,
Format([06],"0.000000") AS TB03
FROM tblPEFactorsPF;

The parameters requested are "txtStart" and "DOV"

As soon as sfrmPortfolioTrades becomes a subform then the reference...

[Forms]![sfrmPortfolioTrades]![FieldName]

....is no longer valid. You have to refer to the form through its subform
control on the parent. Bascially no matter how many levels deep you nest
subforms the ONLY form that can be referenced via Forms!Whatever... is the
top-most form. All other forms have to use...

Forms!TopLevelFormName!SubformControlName.Form![fieldName]

The above would see a subform nested one level down. To go two levels down
you would need...

Forms!TopLevelFormName!SubformControlName.Form!SubformControlName.Form![FieldName]

A common "gotcha" with this syntax is that it requires the name of the
Subform control which is not guaranteed to have the same name as the form
contained within. When the subform is created by dragging a form onto the
parent in design view or with the form wizard the control will usually be
given the same name as the form inside it, but if that name is already in
use then even in those cases the subform control will just end up with a
name like Child1 or similar.

 

[ragtopcaddy via AccessMonster.com]

Thanks a million!

I have a subform whose recordsource is a query that refers to
controls on its parent form.

[quoted text clipped - 23 lines]

The parameters requested are "txtStart" and "DOV"

As soon as sfrmPortfolioTrades becomes a subform then the reference...

[Forms]![sfrmPortfolioTrades]![FieldName]

...is no longer valid. You have to refer to the form through its subform
control on the parent. Bascially no matter how many levels deep you nest
subforms the ONLY form that can be referenced via Forms!Whatever... is the
top-most form. All other forms have to use...

Forms!TopLevelFormName!SubformControlName.Form![fieldName]

The above would see a subform nested one level down. To go two levels down
you would need...

Forms!TopLevelFormName!SubformControlName.Form!SubformControlName.Form![FieldName]

A common "gotcha" with this syntax is that it requires the name of the
Subform control which is not guaranteed to have the same name as the form
contained within. When the subform is created by dragging a form onto the
parent in design view or with the form wizard the control will usually be
given the same name as the form inside it, but if that name is already in
use then even in those cases the subform control will just end up with a
name like Child1 or similar.