Unrelated records can export (as if related) producing ‘ghost’ parent (or child) data when no related record exists.
FMPA 11.0v3, FMPA 9.0v3, FMPA 8.5v1, FMPA 8.0v3, FMPA 7.0v3
Operating system version
Windows XP Professional SP3
Description of the issue
Standard relationship of Parent::ParentID = Child::ParentID.
See sample fp7 file here: http://www.directlinesolutions.com/downloads/GhostParent.zip
... file created by Comment to show the issue. I added two additional calculations.
Steps to reproduce the problem
ChildID 4 has no Parent. But if a Parent calc is either 1) unstored with only Get functions - no fields referenced or 2) the Parent calc is unstored and ‘do not evaluate’ is unchecked, it produces the following unexpected results:
1) On a Child layout with no Parent, it displays these ghost Parent calculations.
2) Cursor can enter those Parent calc fields although it should be prohibited if relationship is invalid.
3) Exporting the Child record and including those Parent calculations exports those values as if the relationship were valid.
1) Placing Parent fields on Child layout should produce ONLY empty Parent calculations otherwise it can confuse because it looks like the relationship is valid.
2) Those Parent fields should not be enterable on the Child record (since there is no valid relationship). It adds to the illusion that a valid relationship exists when it does not.
3) If exporting that Child record (and including Parent fields) then the Parent fields for that Child record should remain empty. It DOES work properly, however, if XML format is selected.
See Description of Issue. Save As Excel also improperly includes the Parent calculations on the Parentless Child. Relationships flow both ways and this means that Parents without Children (which would be more common) will suffer the same issue.
Exact text of any error message(s) that appear
Discovery thread is here: http://fmforums.com/forum/topic/82302-empty-relationship-producing-spaces-in-field/page__fromsearch__1
originally posted by jkluchnik
In the example of cFullName, it is true that the calculation can be stored but not all concatenations are from same record. In this instance, selecting checkbox 'do not evaluate if all referenced fields are empty' resolves it.
Being aware of the issue (until fixed) is key. Workarounds would include constructing formulae with, not only the results in mind, but also considering how related unstored calculation fields might display (and export) if placed on related-table layouts, PDFs etc.
EDITED: Remove 'in portals' since ghosts do not show up in portals.