In image 1, the Delivery Patieint ID is blank. If this is a new parent record shouldn't that field be filled in before you stat creating child table records?
I think what is happening is in image 2, when you tab you are really creating both a parent and child record. So in Image 3 you see the Parent ID, but need a refresh to actually see the first child. It was created, just not seen... yet. In 4 when you enter the last name, you end up creating a second child record. After that I bet you can create as many records correctly as you want.
In the parent record is the Delivery Patient ID set to be an auto-enter/do not replace calculations? get(UUID). So that it fills in when the record is created?
Message was edited by: Bruce Herbach
"In image 1, the Delivery Patieint ID is blank. If this is a new parent record shouldn't that field be filled in before you stat creating child table records?"
Not necessarly. When you create the related reord by typing in the portal FM should match up the key field pair--which is what happens in fact: the forign key in the parent record is set to match the rlated record.
"I think what is happening is in image 2, when you tab you are really creating both a parent and child record." No , the parent record has been created and already committed before the experiment begins
"In the parent record is the Delivery Patient ID set to be an auto-enter/do not replace calculations? get(UUID)" No, it is not set until we type into the portal. There is no refresh until the very last step after typing into the Last Name field
Somehow this seems backwards. I usualy have the primary key created in the the parent record and have it populate in the child record. The child has it's own Primary key, but it is not part of the relationship.
In your setup, if you add OnObjectExit script trigger that commits the record it should populate the parent record field and leave you in the correct last name field.
The relationship is many deliveries => one patient
The user creates a delivery and the chooses a patient or creates a new one -- so the patient id in Deliveries has to come from the patient table.
I have found a workaround -- that was not the question, but rather whether this expected behavior -- I certainly did not expect it - would expect to be be to type into more than one field in the auto create portal before commtting and create a single related record.
I will test with v11 and see if the same thing happens
I agree with Bruce's reservations about the technique your are using and it will break down if there is a possibility of more than one patient per delivery.
If you each delivery involves one patient only, the attached test file will work, as follows:
1. There is a list of existing patients attached to the patientID field. Selecting from the list will link that patient to that delivery.
2. If it is a new patient, typing the patient's name in the fields in the one-record portal will both create that patient and link the record to the delivery record
TEST_parentChild.fmp12.zip 14.5 K
Please read my commentscarefully. There is only ever one patient per delivery. But often more than one delivery per patient.
I have it set up so that the user can a create related patient record if they simply typing his/her name into the apprpriate fields.
I did not ask how to work around this issue or for other ways of getting the job done: as I said in the very first post I have already solved that problem (I have been a Flemaker developer since verion 2)
My question is purely theoretical and intended for the curious among us: why does the auto creation of related record not work in this case?
1 of 1 people found this helpful
I tried replicating your problem and couldn't. As soon as I tab from first name to last name, the ID populates (in both tables) as expected. Are you sure you don't have any script triggers firiing?
Can you post a file showing the issue?
It's all about commitment.
You are creating race condition which is causing the problem. The child record demands that a valid relationship is established and passes the data back to the parent. However, nothing has to happen until the data is entered. You are still editing in the child record and the parent record is not being commited. This is deliberate behaviour and correct. You exit the field and the child record must send its ID back to the parent to establish the relationship. The tab moves to the next field, There is now an entry in the delivery patient ID fied, however, the parent is not committed. Without that commitment the parent doesn't recognise the child and the record containing the first name vanishes. Data entry begins in the last name field. This time there is data in the Delivery Patient ID field and that is used to generate a relationship with the child. Now that the data is committed the relationship with the first child is valid too. It can now be displayed.
why are you using a portal if this is a one to one relationship? Using the related fields without a portal would solve this problem.
Attached is a DB that create a child record in the manner you describe in the original post. When you enter the first name and tab, it creates the record, it also create a blank second record in the portal. Of course the second record doesn't exist yet... But you do end up in the last name field of the original new record. The patient ID field in the parent record does populate with the ID of the first patient record created.
Now the interesting part. As you described, the PatientID field in the child record is setup as an Auto-enter/do not replace field with the formula get(UUID). When the first child record is created it creates the UUID and it is applied to the Parent record. When the second child record is created, it gets the UUID from the parent. The relationship between the tables enforces this.
So at least in this demo, it is creating the records and I get only one record when I tab from First name to Last in the portal.
I'm not sure why your original file actually created a second record. Possibly the tab order is off and when you tabbed you didn't go directly to the last name field... But that doesn't sound quite right...
PatientID.fmp12.zip 9.0 K
Thanks. Yes it should work and I was right to expect it to. I apologize for not making my qiestion clearer - which was "should this work, or is there somethig else making it not work?"
I did have some script triggers running but none of tem affected thee relationshio or the key feild values, yet some how they interfered wuth the process. I still have not found out how they did, that. But a simple example with no triggers works fine.