Referential Reference to Parent Form in Query Criteria

[jimo]

For the source of a subform, I have a query that has as one of its sources a
second query that is dependent on the value of a field in the parent form.
For example:

The data source for subFormA is QueryA. QueryA depends on QueryB (to avoid
ambiguous join issues, otherwise I would combine them in a single query), and
Query B depends on with ControlA field on 'FormParent'.

I don't want to explicitly include the reference to 'FormParent' in QueryB,
however, as I need to maintain a second copy of the FormParent to support
some popup functionality.

Is there a way to reference a control on the parent form referentially
(i.e., without specifying it by name) as a critieria from the Query? If I
was simply in the form, I could use Me.ControlName and be done with it, but
since I needed to run this from a separate query it appears a bit less
straightforward...

I tried [Forms]![subFormA].Parent!ControlA, but that didn't seem to work.
[Forms]![FormParent]![ControlA] works, but requires me to maintain separate
sets of queries and subforms to work with the different copies of the parent
forms...

 

[Jeff Boyce]

I'm not exactly clear on how your subform is "connected" to your main form.

In a standard main form/subform design, the subform control (on the main
form) has Parent and Child properties that you set so the subform
automatically finds the child records related to the record selected for the
main form. No additional querying needed.

Is this how your form/subform is set up?

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[jimo]

Thanks for the reply Jeff.

It is a bit more complicated than a simple form/subform relationship. The
two are related based on the ID of the Parent Record and the Foreign Key of
the Child Record from the query (as you suggest below). However, the query
for the child records relies on another query that depends on a value in the
Parent form.

At the risk of giving you more information than is useful, I am using this
to create a form where all the data that is potentially related to the record
can be presented, with checkboxes showing where associations already exist
(so users can quickly check boxes to make associations between the records,
rather than selecting in a series of combo boxes), but that are filtered
based on a selection in another subform. The second query is used to ensure
the data that is shown in the list is filtered as appropriate. This all
works fine, except it is a bit unpleasant to manage when I want to copy the
parent form (since I currently need to maintain separate subforms and queries
that reference the parent form by name).

Clear as mud?

I'm not exactly clear on how your subform is "connected" to your main form.

In a standard main form/subform design, the subform control (on the main
form) has Parent and Child properties that you set so the subform
automatically finds the child records related to the record selected for the
main form. No additional querying needed.

Is this how your form/subform is set up?

Regards

Jeff Boyce
Microsoft Office/Access MVP

For the source of a subform, I have a query that has as one of its sources
a
second query that is dependent on the value of a field in the parent form.
For example:

The data source for subFormA is QueryA. QueryA depends on QueryB (to
avoid
ambiguous join issues, otherwise I would combine them in a single query),
and
Query B depends on with ControlA field on 'FormParent'.

I don't want to explicitly include the reference to 'FormParent' in
QueryB,
however, as I need to maintain a second copy of the FormParent to support
some popup functionality.

Is there a way to reference a control on the parent form referentially
(i.e., without specifying it by name) as a critieria from the Query? If I
was simply in the form, I could use Me.ControlName and be done with it,
but
since I needed to run this from a separate query it appears a bit less
straightforward...

I tried [Forms]![subFormA].Parent!ControlA, but that didn't seem to work.
[Forms]![FormParent]![ControlA] works, but requires me to maintain
separate
sets of queries and subforms to work with the different copies of the
parent
forms...

 

[Jeff Boyce]

I tend to be too literal (or so my spouse tells me <g>).

Can you provide an example in data without breaching confidence or NDA?

It all starts with the data, and I'm not clear on that yet...

Regards

Jeff Boyce
Microsoft Office/Access MVP

Thanks for the reply Jeff.

It is a bit more complicated than a simple form/subform relationship. The
two are related based on the ID of the Parent Record and the Foreign Key
of
the Child Record from the query (as you suggest below). However, the
query
for the child records relies on another query that depends on a value in
the
Parent form.

At the risk of giving you more information than is useful, I am using this
to create a form where all the data that is potentially related to the
record
can be presented, with checkboxes showing where associations already exist
(so users can quickly check boxes to make associations between the
records,
rather than selecting in a series of combo boxes), but that are filtered
based on a selection in another subform. The second query is used to
ensure
the data that is shown in the list is filtered as appropriate. This all
works fine, except it is a bit unpleasant to manage when I want to copy
the
parent form (since I currently need to maintain separate subforms and
queries
that reference the parent form by name).

Clear as mud?

I'm not exactly clear on how your subform is "connected" to your main
form.

In a standard main form/subform design, the subform control (on the main
form) has Parent and Child properties that you set so the subform
automatically finds the child records related to the record selected for
the
main form. No additional querying needed.

Is this how your form/subform is set up?

Regards

Jeff Boyce
Microsoft Office/Access MVP

For the source of a subform, I have a query that has as one of its
sources
a
second query that is dependent on the value of a field in the parent
form.
For example:

The data source for subFormA is QueryA. QueryA depends on QueryB (to
avoid
ambiguous join issues, otherwise I would combine them in a single
query),
and
Query B depends on with ControlA field on 'FormParent'.

I don't want to explicitly include the reference to 'FormParent' in
QueryB,
however, as I need to maintain a second copy of the FormParent to
support
some popup functionality.

Is there a way to reference a control on the parent form referentially
(i.e., without specifying it by name) as a critieria from the Query?
If I
was simply in the form, I could use Me.ControlName and be done with it,
but
since I needed to run this from a separate query it appears a bit less
straightforward...

I tried [Forms]![subFormA].Parent!ControlA, but that didn't seem to
work.
[Forms]![FormParent]![ControlA] works, but requires me to maintain
separate
sets of queries and subforms to work with the different copies of the
parent
forms...

 

[jimo]

You bet. What's the best way to do that? A stripped down version of the
..mdb?

Best, Jim

I tend to be too literal (or so my spouse tells me <g>).

Can you provide an example in data without breaching confidence or NDA?

It all starts with the data, and I'm not clear on that yet...

Regards

Jeff Boyce
Microsoft Office/Access MVP

Thanks for the reply Jeff.

It is a bit more complicated than a simple form/subform relationship. The
two are related based on the ID of the Parent Record and the Foreign Key
of
the Child Record from the query (as you suggest below). However, the
query
for the child records relies on another query that depends on a value in
the
Parent form.

At the risk of giving you more information than is useful, I am using this
to create a form where all the data that is potentially related to the
record
can be presented, with checkboxes showing where associations already exist
(so users can quickly check boxes to make associations between the
records,
rather than selecting in a series of combo boxes), but that are filtered
based on a selection in another subform. The second query is used to
ensure
the data that is shown in the list is filtered as appropriate. This all
works fine, except it is a bit unpleasant to manage when I want to copy
the
parent form (since I currently need to maintain separate subforms and
queries
that reference the parent form by name).

Clear as mud?

I'm not exactly clear on how your subform is "connected" to your main
form.

In a standard main form/subform design, the subform control (on the main
form) has Parent and Child properties that you set so the subform
automatically finds the child records related to the record selected for
the
main form. No additional querying needed.

Is this how your form/subform is set up?

Regards

Jeff Boyce
Microsoft Office/Access MVP

For the source of a subform, I have a query that has as one of its
sources
a
second query that is dependent on the value of a field in the parent
form.
For example:

The data source for subFormA is QueryA. QueryA depends on QueryB (to
avoid
ambiguous join issues, otherwise I would combine them in a single
query),
and
Query B depends on with ControlA field on 'FormParent'.

I don't want to explicitly include the reference to 'FormParent' in
QueryB,
however, as I need to maintain a second copy of the FormParent to
support
some popup functionality.

Is there a way to reference a control on the parent form referentially
(i.e., without specifying it by name) as a critieria from the Query?
If I
was simply in the form, I could use Me.ControlName and be done with it,
but
since I needed to run this from a separate query it appears a bit less
straightforward...

I tried [Forms]![subFormA].Parent!ControlA, but that didn't seem to
work.
[Forms]![FormParent]![ControlA] works, but requires me to maintain
separate
sets of queries and subforms to work with the different copies of the
parent
forms...

 

[Jeff Boyce]

Actually, if you could just post a simplified description of your data
structure and an example of the data that you're storing...

Here's a simplistic model I use:

tblPerson
PersonID
FirstName
LastName

tblClass
ClassID
ClassTitle

trelEnrollment
EnrollmentID
PersonID
ClassID
EnrollmentDate

Hopefully the table and field names are descriptive enough for you to
reasonably guess what I'm storing in the fields...


Regards

Jeff Boyce
Microsoft Office/Access MVP

You bet. What's the best way to do that? A stripped down version of the
.mdb?

Best, Jim

I tend to be too literal (or so my spouse tells me <g>).

Can you provide an example in data without breaching confidence or NDA?

It all starts with the data, and I'm not clear on that yet...

Regards

Jeff Boyce
Microsoft Office/Access MVP

Thanks for the reply Jeff.

It is a bit more complicated than a simple form/subform relationship.
The
two are related based on the ID of the Parent Record and the Foreign
Key
of
the Child Record from the query (as you suggest below). However, the
query
for the child records relies on another query that depends on a value
in
the
Parent form.

At the risk of giving you more information than is useful, I am using
this
to create a form where all the data that is potentially related to the
record
can be presented, with checkboxes showing where associations already
exist
(so users can quickly check boxes to make associations between the
records,
rather than selecting in a series of combo boxes), but that are
filtered
based on a selection in another subform. The second query is used to
ensure
the data that is shown in the list is filtered as appropriate. This
all
works fine, except it is a bit unpleasant to manage when I want to copy
the
parent form (since I currently need to maintain separate subforms and
queries
that reference the parent form by name).

Clear as mud?


:

I'm not exactly clear on how your subform is "connected" to your main
form.

In a standard main form/subform design, the subform control (on the
main
form) has Parent and Child properties that you set so the subform
automatically finds the child records related to the record selected
for
the
main form. No additional querying needed.

Is this how your form/subform is set up?

Regards

Jeff Boyce
Microsoft Office/Access MVP

For the source of a subform, I have a query that has as one of its
sources
a
second query that is dependent on the value of a field in the parent
form.
For example:

The data source for subFormA is QueryA. QueryA depends on QueryB
(to
avoid
ambiguous join issues, otherwise I would combine them in a single
query),
and
Query B depends on with ControlA field on 'FormParent'.

I don't want to explicitly include the reference to 'FormParent' in
QueryB,
however, as I need to maintain a second copy of the FormParent to
support
some popup functionality.

Is there a way to reference a control on the parent form
referentially
(i.e., without specifying it by name) as a critieria from the Query?
If I
was simply in the form, I could use Me.ControlName and be done with
it,
but
since I needed to run this from a separate query it appears a bit
less
straightforward...

I tried [Forms]![subFormA].Parent!ControlA, but that didn't seem to
work.
[Forms]![FormParent]![ControlA] works, but requires me to maintain
separate
sets of queries and subforms to work with the different copies of
the
parent
forms...

 

[jimo]

You bet, but apologies in advance for the long post. For this I will drop
the abstraction that I was trying to use to make it easier to digest. So the
application that I'm working with is a software requirements management
system, and this particular portion of it is for capturing the data elements
associated with requirements.

*************************************
The relevant data structure is:

tbl_Requirements (the main requirements table)
ID
RequirementName
(plus a lot of additional fields not important here)

tbl_DataFields (table of all the Fields needed)
ID
DataSubjectID
Field
(plus other fields)

tbl_DataSubjects (table of the Data Subjects, used to group the data fields)
ID
DataSubject
(plus other fields)

tix_ReqDataSubject (intersection table between requirements and data subjects)
ID
ReqID
DataSubjectID

tix_ReqDataField (intersection table between requirements and data fields)
ID
ReqID
DataFieldID

*********************************
If you're still with me, this data is leveraged by three forms:

1. frm_RequirementsEntry (the parent form)

2. fsub_DataSubjects (subform used to select and display the records from
tix_ReqDataSubject)
-Link Child Field: ReqID; Link Master Fields: ID
-to enable the fsub_ReqDataFields to display the records associated with the
active record in fsub_DataSubjects, I have an unbound field (txtlink3) on the
parent form (frm_RequirementsEntry) that is set in VBA to be equal to the
DataSubjectID (on current, change, etc.).

3. fsub_ReqDataFields (the subform used to select and display the records
from tix_ReqDataField for the active record selected in fsub_DataSubjects)
-Link Child Field: DataSubjectID; Link Master Fields: txtlink3
-this subform presents ALL of the records in the tbl_DataFields that match
the DataSubject (based on the links above), whether or not they are
associated to the Requirement of the parent form. If there is a
corresponding record in the tix_ReqDataField, we show a checkbox with a true
value (indicating that this datafield is associated to this requirement).
The SQL for this form is: SELECT tbl_DataFields.*,
IIf(IsNull([qry_ReqDataMatched].[ID]),False,True) AS RelatedCheckbox
FROM tbl_DataFields LEFT JOIN qry_ReqDataMatched ON tbl_DataFields.ID =
qry_ReqDataMatched.ID
ORDER BY tbl_DataFields.Sort;

The challenge is that the data source for the qry_ReqDataMatched used above
references the ID field on the parent form. The SQL is: SELECT
tbl_DataFields.*, tix_ReqDataField.ReqID
FROM tbl_DataFields INNER JOIN tix_ReqDataField ON tbl_DataFields.ID =
tix_ReqDataField.DataFieldID
WHERE (((tix_ReqDataField.ReqID)=[Forms]![frm_RequirementsEntry]![ID]));

While a bit convoluted, all of this works. The rub is that I have to
maintain a second copy of the frm_RequirementsEntry (called fsub_ReqPopup)
that is used to launch (from frm_RequirementsEntry) another version of the
form (e.g., to show a second requirement that has been linked to the first).
fsub_ReqPopup is identical to the frm_RequirementsEntry, with all of the same
controls, subforms, etc. except that I need to maintain a second version of
fsub_ReqDataFields (and qryReqDataMatched) so that the criteria is pointing
to the appropriate requirement value in the parent form (e.g., for the popup,
the criteria ends up being ...WHERE
(((tix_ReqDataField.ReqID)=[Forms]![fsub_ReqPopup]![ID]));

*************
So what I'm hoping that there is a way to reference the parent form from the
query without referring to the parent form by name. I tried
[Forms]![fsub_ReqDataFields].Parent!ID, but that didn't seem to work...

Appreciate your reading this far! Is there a syntax that will do this?

Best, Jim

 

[Jeff Boyce]

Jim

See comments in-line below... and at end.

You bet, but apologies in advance for the long post. For this I will drop
the abstraction that I was trying to use to make it easier to digest. So
the
application that I'm working with is a software requirements management
system, and this particular portion of it is for capturing the data
elements
associated with requirements.

*************************************
The relevant data structure is:

tbl_Requirements (the main requirements table)
ID
RequirementName
(plus a lot of additional fields not important here)

tbl_DataFields (table of all the Fields needed)
ID
DataSubjectID
Field
(plus other fields)

tbl_DataSubjects (table of the Data Subjects, used to group the data
fields)
ID
DataSubject
(plus other fields)

tix_ReqDataSubject (intersection table between requirements and data
subjects)
ID
ReqID
DataSubjectID

If you are already capturing which DataSubject each DataField belongs in,
this table may be redundant given the following table.

tix_ReqDataField (intersection table between requirements and data fields)
ID
ReqID
DataFieldID


*********************************
If you're still with me, this data is leveraged by three forms:

1. frm_RequirementsEntry (the parent form)

2. fsub_DataSubjects (subform used to select and display the records from
tix_ReqDataSubject)
-Link Child Field: ReqID; Link Master Fields: ID
-to enable the fsub_ReqDataFields to display the records associated with
the
active record in fsub_DataSubjects, I have an unbound field (txtlink3) on
the
parent form (frm_RequirementsEntry) that is set in VBA to be equal to the
DataSubjectID (on current, change, etc.).

.... and if the DataSubjects table is redundant, so's this form. I suspect
you could get away with using a combobox in your DataFields subform to
assign/select the correct category.

3. fsub_ReqDataFields (the subform used to select and display the records
from tix_ReqDataField for the active record selected in fsub_DataSubjects)
-Link Child Field: DataSubjectID; Link Master Fields: txtlink3
-this subform presents ALL of the records in the tbl_DataFields that match
the DataSubject (based on the links above), whether or not they are
associated to the Requirement of the parent form. If there is a
corresponding record in the tix_ReqDataField, we show a checkbox with a
true
value (indicating that this datafield is associated to this requirement).

Not sure I'm following the "checkbox" part. Are you saying that the
DataField table is like a spreadsheet, where each DataField gets its own
column? That isn't what I understood from above description.

The SQL for this form is: SELECT tbl_DataFields.*,
IIf(IsNull([qry_ReqDataMatched].[ID]),False,True) AS RelatedCheckbox
FROM tbl_DataFields LEFT JOIN qry_ReqDataMatched ON tbl_DataFields.ID =
qry_ReqDataMatched.ID
ORDER BY tbl_DataFields.Sort;

The challenge is that the data source for the qry_ReqDataMatched used
above
references the ID field on the parent form. The SQL is: SELECT
tbl_DataFields.*, tix_ReqDataField.ReqID
FROM tbl_DataFields INNER JOIN tix_ReqDataField ON tbl_DataFields.ID =
tix_ReqDataField.DataFieldID
WHERE (((tix_ReqDataField.ReqID)=[Forms]![frm_RequirementsEntry]![ID]));

While a bit convoluted, all of this works. The rub is that I have to
maintain a second copy of the frm_RequirementsEntry (called fsub_ReqPopup)
that is used to launch (from frm_RequirementsEntry) another version of the
form (e.g., to show a second requirement that has been linked to the
first).
fsub_ReqPopup is identical to the frm_RequirementsEntry, with all of the
same
controls, subforms, etc. except that I need to maintain a second version
of
fsub_ReqDataFields (and qryReqDataMatched) so that the criteria is
pointing
to the appropriate requirement value in the parent form (e.g., for the
popup,
the criteria ends up being ...WHERE
(((tix_ReqDataField.ReqID)=[Forms]![fsub_ReqPopup]![ID]));

I'm not following why the second set is needed.

*************
So what I'm hoping that there is a way to reference the parent form from
the
query without referring to the parent form by name. I tried
[Forms]![fsub_ReqDataFields].Parent!ID, but that didn't seem to work...

Appreciate your reading this far! Is there a syntax that will do this?

Best, Jim

You've described "how" you are trying to accomplish something (duplicate set
of forms, using query on form to alter what shows in subform, etc.).

What I don't quite get yet is what having this working will allow you to do?
I understand (I think) the technical part, but it's the business need that
this is supposed to satisfy that's eluding me.

Are you saying that you want a way to track DataFields by Requirement and
Subject? I believe you can do that easily with queries, if your data
structure does NOT have that redundant junction table.

Or maybe I just don't get it <g>...

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[jimo]

Hi Jeff,
I included a couple of responses below, but maybe a picture would help most.
Here is a link to an image of the two subforms that exist on the parent
requirements form:

http://www.flickr.com/photos/31040613@N04/2907296105/


The checkboxes are used to indicate that there is a relationship between the
datafield and the requirement (and used to easily create such a
relationship).

Does this help?

Best, Jim

Jim

See comments in-line below... and at end.




If you are already capturing which DataSubject each DataField belongs in,
this table may be redundant given the following table.

[JIM: agreed, this is just for user convenience (so the user isn't presented
with all possible fields at once)]

.... and if the DataSubjects table is redundant, so's this form. I suspect
you could get away with using a combobox in your DataFields subform to
assign/select the correct category.

[JIM: we could, but it would get pretty overwhelming for the user]

Not sure I'm following the "checkbox" part. Are you saying that the
DataField table is like a spreadsheet, where each DataField gets its own
column? That isn't what I understood from above description.

[JIM: see the link above, hopefully that will make it more clear]

The SQL for this form is: SELECT tbl_DataFields.*,
IIf(IsNull([qry_ReqDataMatched].[ID]),False,True) AS RelatedCheckbox
FROM tbl_DataFields LEFT JOIN qry_ReqDataMatched ON tbl_DataFields.ID =
qry_ReqDataMatched.ID
ORDER BY tbl_DataFields.Sort;

The challenge is that the data source for the qry_ReqDataMatched used
above
references the ID field on the parent form. The SQL is: SELECT
tbl_DataFields.*, tix_ReqDataField.ReqID
FROM tbl_DataFields INNER JOIN tix_ReqDataField ON tbl_DataFields.ID =
tix_ReqDataField.DataFieldID
WHERE (((tix_ReqDataField.ReqID)=[Forms]![frm_RequirementsEntry]![ID]));

While a bit convoluted, all of this works. The rub is that I have to
maintain a second copy of the frm_RequirementsEntry (called fsub_ReqPopup)
that is used to launch (from frm_RequirementsEntry) another version of the
form (e.g., to show a second requirement that has been linked to the
first).
fsub_ReqPopup is identical to the frm_RequirementsEntry, with all of the
same
controls, subforms, etc. except that I need to maintain a second version
of
fsub_ReqDataFields (and qryReqDataMatched) so that the criteria is
pointing
to the appropriate requirement value in the parent form (e.g., for the
popup,
the criteria ends up being ...WHERE
(((tix_ReqDataField.ReqID)=[Forms]![fsub_ReqPopup]![ID]));

I'm not following why the second set is needed.

*************
So what I'm hoping that there is a way to reference the parent form from
the
query without referring to the parent form by name. I tried
[Forms]![fsub_ReqDataFields].Parent!ID, but that didn't seem to work...

Appreciate your reading this far! Is there a syntax that will do this?

Best, Jim

You've described "how" you are trying to accomplish something (duplicate set
of forms, using query on form to alter what shows in subform, etc.).

What I don't quite get yet is what having this working will allow you to do?
I understand (I think) the technical part, but it's the business need that
this is supposed to satisfy that's eluding me.

Are you saying that you want a way to track DataFields by Requirement and
Subject? I believe you can do that easily with queries, if your data
structure does NOT have that redundant junction table.

Or maybe I just don't get it <g>...

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[Jeff Boyce]

Jim

I'm probably out of my depth on this one if you need to keep that multiple
checkbox approach. I'd probably use something like in my earlier responses.

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

Hi Jeff,
I included a couple of responses below, but maybe a picture would help
most.
Here is a link to an image of the two subforms that exist on the parent
requirements form:

http://www.flickr.com/photos/31040613@N04/2907296105/


The checkboxes are used to indicate that there is a relationship between
the
datafield and the requirement (and used to easily create such a
relationship).

Does this help?

Best, Jim

Jim

See comments in-line below... and at end.




If you are already capturing which DataSubject each DataField belongs in,
this table may be redundant given the following table.

[JIM: agreed, this is just for user convenience (so the user isn't
presented
with all possible fields at once)]

.... and if the DataSubjects table is redundant, so's this form. I
suspect
you could get away with using a combobox in your DataFields subform to
assign/select the correct category.

[JIM: we could, but it would get pretty overwhelming for the user]

Not sure I'm following the "checkbox" part. Are you saying that the
DataField table is like a spreadsheet, where each DataField gets its own
column? That isn't what I understood from above description.

[JIM: see the link above, hopefully that will make it more clear]

The SQL for this form is: SELECT tbl_DataFields.*,
IIf(IsNull([qry_ReqDataMatched].[ID]),False,True) AS RelatedCheckbox
FROM tbl_DataFields LEFT JOIN qry_ReqDataMatched ON tbl_DataFields.ID =
qry_ReqDataMatched.ID
ORDER BY tbl_DataFields.Sort;

The challenge is that the data source for the qry_ReqDataMatched used
above
references the ID field on the parent form. The SQL is: SELECT
tbl_DataFields.*, tix_ReqDataField.ReqID
FROM tbl_DataFields INNER JOIN tix_ReqDataField ON tbl_DataFields.ID =
tix_ReqDataField.DataFieldID
WHERE
(((tix_ReqDataField.ReqID)=[Forms]![frm_RequirementsEntry]![ID]));

While a bit convoluted, all of this works. The rub is that I have to
maintain a second copy of the frm_RequirementsEntry (called
fsub_ReqPopup)
that is used to launch (from frm_RequirementsEntry) another version of
the
form (e.g., to show a second requirement that has been linked to the
first).
fsub_ReqPopup is identical to the frm_RequirementsEntry, with all of
the
same
controls, subforms, etc. except that I need to maintain a second
version
of
fsub_ReqDataFields (and qryReqDataMatched) so that the criteria is
pointing
to the appropriate requirement value in the parent form (e.g., for the
popup,
the criteria ends up being ...WHERE
(((tix_ReqDataField.ReqID)=[Forms]![fsub_ReqPopup]![ID]));

I'm not following why the second set is needed.

*************
So what I'm hoping that there is a way to reference the parent form
from
the
query without referring to the parent form by name. I tried
[Forms]![fsub_ReqDataFields].Parent!ID, but that didn't seem to work...

Appreciate your reading this far! Is there a syntax that will do this?

Best, Jim

You've described "how" you are trying to accomplish something (duplicate
set
of forms, using query on form to alter what shows in subform, etc.).

What I don't quite get yet is what having this working will allow you to
do?
I understand (I think) the technical part, but it's the business need
that
this is supposed to satisfy that's eluding me.

Are you saying that you want a way to track DataFields by Requirement and
Subject? I believe you can do that easily with queries, if your data
structure does NOT have that redundant junction table.

Or maybe I just don't get it <g>...

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP