Re: LinkMaster>LinkChild problem

comments inline.

"Amy Blankenship" <Amy_nospam@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:OEl9iayPHHA.4364@xxxxxxxxxxxxxxxxxxxxxxx

"tina" <nospam@xxxxxxxxxxx> wrote in message
news:cRfth.445984$Fi1.124979@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
When I looked in the related tables, the record was
created in the child table, but its ID had not been inserted in the
parent
table (the record source for Subform 2).

umm, what? child records have a foreign key field that contains the
primary
key value of the related parent record - but parent records do not
contain
the PK values of their child record(s).

In this case, the Parent/Child structure is reversed, because Subform 2
actually is a child of Subform 1, but Subform 3 has no direct relationship
with Subform 2's parent.

if Subform3 is "sitting" inside Subform2, then it doesn't need to have a
relationship with Subform2's *parent* - it needs to have a relationship with
Subform2.

It's a necessity of nesting that Subform 2 must
act *structurally* as Subform 3's parent, even though in a typical
parent/child secenario the reverse would be true.
Since it is (roughly) a
1:1 relationship, there's no *real* parent or child.

well, first of all, and as i said before, a correctly linked pair of tables
have a *specific* relationship - not "roughly" anything. second, even in a
one-to-one relationship, there is a specific parent table and a specific
child table - as long as the tables are linked correctly, and unless you're
*not* enforcing referential integrity, which in general is a BAD IDEA.

However, since the
"child" table maintains 1:1 relationships with many other tables, you
can't
really put the FK on that side, because then you'd need some other
information to tell you which table that ID actually was referring to.
And
that just gets messy.

don't get hung up on field names (assuming that's what you're referring to).
a foreign key field does NOT have to have the same name as its'
corresponding primary key field in the related table. personally, i *never*
give any two fields in a database identical names, no matter how many tables
and relationships there are.


for that new record in Subform 2 (yes, it's a 1:1 relationship, sort
of).

correctly established table relationships are not "sort of" anything;
they
are a specific type. in the Relationships window, is the link between
the
two tables defined, or does it show as "Indeterminate" (or maybe that's
"Undetermined", i don't remember)?

Since *all* relationships seem to default to one to many and there does
not
seem to be any way to edit that, any 1:1 relationship will be in the head
of
the developer rather than something you can actually force Access to
define.
So while Access believes that the child record could potentially be used
in
many parent records (and I refer to the FORM structure not the TABLE
structure, since this isn't a typical heirarchical thing),

you can't separate the two in that manner. regardless of how you set up
forms, they must adhere to the relational design of their underlying
tables - the data is being stored in the table(s), not the form(s). by
definition, a child record is related to a single record in its' parent
table, you can't alter that data structure no matter what you do with forms.

at this moment it
is being treated as 1:1. Actually, I may wind up reusing the RTF defined
in
the child record in other parent records, but I think that's even more
hoops.

Clearly, I've stepped outside the mental model that Access is best suited
to
handle. However, the exact same structire works in other places, where
different parent forms show and edit a similar child form with no problem.
So I'm at a loss as to what is different here.

i agree with Joan, we need to know what your tables structure is, before we
can hope to offer specific suggestions.


and btw, the Tab control on any form has nothing to do with subforms,
it's
never included in a control reference and does not affect the
form/subform
hierarchy in any way.

I didn't think so, but I felt it was worth mentioning, because it could
actually be relevant. For instance, on a different tab, another subform
acts as a parent to a slightly different subform which references the same
table as the problem subform, but with no problems. Could it be that
having
two different subforms pointing to the same place on different tabs could
break things?

i don't see how. Access won't permit duplicate control names in a form (or a
report, to digress), so from a programming standpoint, there is no such
thing as "the same place on two different tabs" - only two different places
on two different tabs.


-Amy




.

Relevant Pages

  • Re: LinkMaster>LinkChild problem
    ... created in the child table, but its ID had not been inserted in the ... key value of the related parent record - but parent records do not ... In this case, the Parent/Child structure is reversed, because Subform 2 ... a foreign key field does NOT have to have the same name as its' ...
    (microsoft.public.access.forms)
  • Re: LinkMaster>LinkChild problem
    ... created in the child table, but its ID had not been inserted in the ... key value of the related parent record - but parent records do not contain ... In this case, the Parent/Child structure is reversed, because Subform 2 ... For instance, on a different tab, another subform ...
    (microsoft.public.access.forms)
  • Re: Putting a field on a form from another record
    ... you can link the second child subform to the first, ... DOBa) in the first subform control, ... the foreign key field that links the table to the parent table, ...
    (microsoft.public.access.forms)
  • RE: add records to INNER JOIN query
    ... Create a form with the parent table. ... in the child table with the primary key field data in the parent table. ... This is a numeric field in Kabinet named folder_naam. ...
    (microsoft.public.access.queries)
  • Re: What does this mean?
    ... I reversed the parent child coding hoping it would compensate for the ... i'll call the foreign key field Child_ParentID. ... DoCmd.DoMenuItem acFormBar, acEditMenu, 8,, acMenuVer70 ...
    (microsoft.public.access.gettingstarted)
Loading