AnsweredAssumed Answered

Entering Data in "Parent"(?) table field auto enters foreign key

Question asked by philmodjunk on Aug 10, 2012
Latest reply on Sep 10, 2012 by philmodjunk

Summary

Entering Data in "Parent"(?) table field auto enters foreign key

Product

FileMaker Pro

Version

11.03

Operating system version

Windows XP SP3

Description of the issue

Discovered this behavior helping out a person posting to this forum:
A child table is related to a parent table, but with "allow create" enabled for the parent table in the relationship. The primary key field in the parent table is an auto-entered serial number. There are no other auto enter settings and no script triggers involved.
A layout based on the child table includes a different field from the parent. If you create a new record in the child table and then enter data into the field from the parent table, a new record is generated in the parent and it's serial number is copied back into the foreign key field.

Bug or Expected Behavior?

Steps to reproduce the problem

Define two tables: Parent, Child. (given the unusual settings, it's hard to be sure which to call parent and which to call child.) Define a text or number field in parent called "data".

Define a primary key field in Parent as an auto-entered serial number. A data field of matching type in Child with no auto-enter options specified for the foreign key.

Define this relationship:
Parent::PrimaryKey = Child::ForeignKey

Enable "allow creation of records via this relationship" for Parent.

Create a  layout to Child and add "Data" field to it.

Create a new record and note that ForeignKey is blank, thus there is currently no valid relationship matching to any record in Parent. Enter some data into "Data" and commit the record.

Expected result

An error message: "This field cannot be modified until ForeignKey is given a valid value."

Actual result

A new record is created in Parent and the value of PrimaryKey in this new record is entered into the ForeignKey field of the current Child record.

Configuration information

This may be intentionally designed to work this way. It just seems counter intuitive given that there is no valid relationship from Child to Parent when the records are committed.

Normally, we start from a new record in the Parent table and use the "allow create option" to create the child and then there is a valid value in PrimaryKey to copy in to ForeignKey instead of the other way around.

Outcomes