Has anyone else run across this oddness? If so, do you know what's actually happening?

The case:

I have a master table and a slave table, with a defining relationship of Master:Field1 <--> Slave:constant (where constant = 1). This is set to allow creation of related records in slave, so if field1 is 1, all records in slave are related to the master record. Each table also has a key, set to auto-enter serial, but this doesn't play into the relationship.

Now the odd bit: If the relationship is currently valid (i.e., master:field1 = 1), I get an error when I try to create a related record via the portal by filling in a slave:text field in the portal. I get "field cannot be modified", which I assume to mean that the calc field cannot be set, which makes sense, theoretically.

However, if master:field1 is blank (i.e., the relationship should have no matching records in slave), I can enter a related record, which is most unexpected. I enter the slave:text field in the portal and enter a value, and when I commit the record by clicking out of the field, thee relationship automatically sets master:field1 to 1, then creates a related record. It gives no error.

I have attached a sample file. To experiment, just try creating records using the two conditions: when Master:Field1 = 1, and when it is blank. Where no valid relationship exists, it works; where the valid relationship exists, it refuses and gives an error.

PortalAddOdd.fp7.zip

If you are trying to create the related record in the slave table, it tries to assign the match field on the left hand side (Master::Field1 in this case) to the match field on the right hand side (Slave::c_const). However, since c_const is a calc, it can't assign/write it, and the error results.

What if Master::Field1 was a 2? Would you want Slave::c_const to be a 2 also?

Instead of defining SlaveLLc:c_const as a calculation, set it as an auto enter number, where a calculated value of 1 is auto-entered. This gives it the same effect as automatically being a 1, but allows the value to be written so that it can be created via the portal.

Deleted - Dan is correct.

This they now do.

Anyway, my question was not how to create related records using a constant (so many methods, so little time), but why FM7 was exhibiting this interesting behavior, which was (to me) quite unexpected.

If my master file has a value for the relationship (any value: 1, 2, whatever), the related record will not be created, and an error results. But if it has no value, the related record not only gets created, but the master immediately inherits the value from the non-valid relationship, making it valid after all. So, if it can't create related records because the slave field is a calculation, why can it do it when the master field has no value?

In effect, this is an unexpected way of overriding the restriction of using a calculation as the slave field.

Anyway, I thought this was interesting and that someone else might find it interesting, too.