Is the relationship between LB_Order_Info and LB_Order_Item supposed to be 1 to 1? That's what appears to be the case, yet the field naming conventions suggest that it should be one to many in a typical "one order to many listed items" relationship. (There are "crows feet" missing that suggest a unique values validation or auto-entered serial number option on fk_LB_Order_Info and this does not appear to be what should be specified here.)
I don't have time at the moment to look at the other details, but first glance brought that issue to my attention.
I do have an auto-enter serial function in the primary key field for LB_Order_Info. I did notice that the crows feet were missing from some of my one-to-many relationships. Should I not be using an auto enter serial to create a relation field?
An auto enter field option should be specified for the field on the one side of the relationship but usually not on the many side and neither unique values nor prohibit modification should ever be specified for the match field on the many side.
Auto-enter on this side: Parent -----< Children Do NOT auto-enter in the match field on this side
pk = Primary key, fk = foreign key in many field naming conventions. A Primary key has to always have a unique value and this value should never ever be changed for a given record once it has been assigned. A foreign key (in a one to many relationship) does not store a unique value and gets a value set to match the primary key on the other side of the relationship. It's value is assigned via other means such as:
- Automatically copied from the primary key via a "create relationship" as happens when you enter data into the "add row" of a portal.
- A value list used to select the appropriate parent record
- And yes, there are cases where an auto-enter calculation might enter the value, but this would not be an auto-entered serial nor an auto-entered UUID. It would be an expression that copies the needed matching value from another source such as a global field or variable.