Check the base table of the table occurrence your portal is based on for lookup and calculations.
Check any scripts that create records in the portal to see if they perform actions to set data on the portal.
Check the relationships from the parent table to the portal (children) Table Occurrence to see if their is any data being loaded that way.
I don't see a New Record button in your screen shot so im assuming you are talking about the filemaker new record button.
Check to see if the new record menu command is being overwritten in a custom menu.
When looking at the relationships, remember to compare empty field relationships too since that can give results you might not want. But as Coherentkris said, check the primary field in the new record's relationship with the portal table occurrence.
1 of 1 people found this helpful
By the look of your screenshot, it seems to me what you mean is you create a new parent record and the portal data immediately appears. If this is the case, then it is most likely caused by the primaryID field in the parent record being auto populated (as it should be) with perhaps a serial number that is out of sync with what has gone before, and hence it is immediately linking to existing portal records with that serial number.
A parent record contains serial number 1234. A number of child records have been created linking to this parent record.
Some work is done on the file—a new version created perhaps—and the parentID serial number is not properly reset.
Subsequently a new record is created with serial number 1234, making a duplicate, and the portal data belonging to the other 1234 instantly appears.
If that sounds like your case, you will need to search for duplicate parentIDs and resolve this. Then you will need to make sure it can't happen again.
PS: Avoiding this scenario is one of the strongest arguments for using UUIDs instead of serial numbers for primary key fields.
Yes... if there are some 'multi-key' entries in the portal records, this is the 'normal' behavior
If You have one or more records (portal TO) where the foreign key field has 'Carriage Return' characters at the beginning or end, those records have the ID as 'multi key' - and matches empty ID's in the parent record
I forgot that some dont know enough about how to set up a proper pk/fk parent/child relationship.
If the parent pk is duplicate it would definitely produce this issue. Of course then it would NOT actually be a primary key.
FileMaker tends to do exactly what you tell it to do.
Funny how that works.
Note bishop0072 has neglected to tell us that this is an XPOST with FMForums.
Over there, the problem file has actually been posted.
Sadly, Bruce, it was a guess based on bitter experience. I fell for that more than once long years ago and can still feel the egg on my face.
Yes, me too. There was such fun back then updating FM6 solutions with simple serial keys and 60 tables, where table=file=table.