I believe that you have the relationship/portal set to create a record when data is entered. So when you create a new parent record, the portal shows a record that in reality doesn't exist. Start entering data and the record is created and really exists going forward. At the same time a new blank/non-existent record is created in the next portal row. Notice that the X button in the bottom row/ non existent record is missing. Enter data in one of the fields and the button will appear.
A typical way around this is to remove the create record set up and replace it with a button and script to create the new records. If you can get used to the way it is working, you can leave it.
thanks for the thoughtful reply. I'm surprised at the behavior; I've got experience with FMP starting at version 5 and this is the first time I've encountered this little delimna--seems only happening in v12. I'll keep poking about.
No, it has been this way since version 3.
You might want to employ different formatting - for example, make the fields transparent - so that the phantom row is less conspicuous.
This looks different to expected behaviour to me. When the option to allow new records based on related data is selected in the relationship graph, you will see an empty line in the last portal row as indicated by Bruce & Michael.... but I think the question here is about what is causing the values of "line 1" in field 2 and "401K Plan" in field 3 to spread across 2 portal rows.
Some information that might help to solve this includes the following:
1. How is the portal sorted?
2. How are the records in the relationship sorted from the relationship graph)?
3. Are there any filters applied to the portal?
4. Are there any script triggers on any of the fields in the portal?
5. What is the exact tab order number for each of the fields in the portal?
6. How is the data between the parent and child table related?
I had a similar issue in the past related to the way the rows were sorted, but I don't think it affected the first record like this. As suggested by others though, the empty last line can otherwise be altered with formatting or conditional formatting, or by changing the settings for that relationship in the relationship graph.
You are right: there are other issues at work here as well. It seems that the portal (or the underlying relationship) is sorted, so that the lines exchange places at commit. Another thing worth checking, IMHO, is whether the fields in the portal belong to the same TO the portal is pointing to.
I agree with Stephen, that the problem is the way lines 1 and 2 or the portal have parts of what I thouht was supposed to be line 1. Let me try to answer Stephen's questions to clarify what problem I think I'm having.
1. The portal rows are not being sorted
2. the records in the relationship graph are not sorted -- see image below
3. I have not implemented any filters
4. No script triggers in the fields in the portal (although I've tested it with script triggers and the result is the same (more on this below)
5. tab sequence is the default, as the fields appear in the portal
6. as shown in the image above, the two tables are related through what I can the transPkey (parent) and transFkey (child); transPkey is auto-generated serial number; no user input; transFkey is a numeric field that I am assuming is created through the portal auto add field--at least that's how I've used it before and it 'seems' to work. I've verified that transFkey is properly populated with the correct transPkey value depending on the parent/child record set I'm looking at.
In a previous iteration, I had a script trigger that populated the 2nd field; I have since removed this trigger.
as far as I can tell, the fields do belong to the same TO as the portal is tied to; I will reconfirm.
thanks for the feedback on this problem. I have discovered, apparently, that the problem lies in my unwitting transfer of an application from an earlier version to FMP12--I copied the master and child tables and then created a new database and imported those field definitions--preliminary results indicate that the problem described above has been resolved. Somehwere else on these forums someone posted a comment to the discussion topic about a developer who's leaving FM. The comment was to the effect that you shouldn't try to take an earlier FM solution and migrated it to 12. This appears to be the case--some funny things seem to creep into the mix when/if you migrate. I will continue to work this as I bring my solution into FMP12 without migration.
My experience with the move to FM12 has also been that you are best to start from as close to nothing as possible and rebuild from there, especially for a big solution.
yep, I heartedly concur. I just tried using the old framework and copy/paste into the new--no luck. Problem persists. So, I'll have to recreate from scratch. It has been a painful lesson, but I'm learning from it