Entering Data in "Parent"(?) table field auto enters foreign key
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.
An error message: "This field cannot be modified until ForeignKey is given a valid value."
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.
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.