More information is required to give you a good answer. How are the related records being entered? Your question seems to imply you're adding them from another window or workstation. If so, then you won't see them until (a) the record is committed, (b) your cache refreshes (maybe) at idle, and / or (c) the portal refreshes.
If that's not the issue, then it's possible the key field on which the relationship is based has indexing issues.
But we need to know more about your setup before answering.
you do not tell which version you use. To make sure, as you guessed, you need to refresh the portal. First you need to give the portal a name: to do this select the portal in Layout mode, bring the Inspector, go the left tab (Position) and type a name in the Name text box. Then:
- if you have version 14, use the script step Refresh Portal [ portalName ]
- if you have a previous version , the use Refresh Object [ portalName ]
Thing is portal is not refreshed automatically most of the time.
Although quite brutal, the script step
Refresh window [Flush cached join results]
will always do.
Thanks for the reply, but before i get into too much detail.
Yes the records have been committed.
Is it possible to manually "refresh Cache" and or "refresh Portal"?
**Just saw other replies. I will try those first. I am using FM 14 Pro advanced**
I tried Refresh Object, Refresh Windows and Refresh Portal all to no avail. The only way it will show up is if i delete the record and fill it out a new one exactly the same as the other one, but this time it does show up. Obviously moving forward this will not due.
Have you checked the indexes on the key fields? There may be something there. Turn indexing off and let FileMaker rebuild them.
Thanks Mike_Mitchell the records are displaying correctly.
But now i have a new issue. I would like to reduce the number of old records this portal displays.
Ive used 'Omit Multiple Records [No Dialog ; Get (FoundCount) - 1000 ]' before to limit records before but as you know i can not apply this to the portal filter.
Omit won't help you; it works based on the current context. In order to cut down the display through a portal, you have to either filter the portal via the filtering feature, or modify the relationship so it constrains the fetched set.
"filter the portal via the filtering feature"
That sounds great. How do i limit the number of records displayed via filtering feature?
Well, you said you wanted to omit the "old" records. Which ones are those?
"old" records would be all records except the last 1000.
Just need to see the last 100 or so.
*1000 not 100*
In that case, you would need to create an unstored calculation field in the child table equal to Get ( RecordNumber ). Then filter the portal based on childTable::recordNumberField < 1001. Or, just use a serial number (just make sure you account for gaps created by deleting records).
Note: This is not a really good strategy for a networked solution with potentially a lot of records. The performance hit of portal filters is significant, and filtering on an unstored calculation will slow it down more. Modifying the relationship will likely prove better from a performance standpoint.
What you could do is the following:
- Add a DisplayMe field to the portal table, it gets a 1 via autoenter on record creation.
- Add a creationTimeStamp to the portal table, if you don't have it yet.
- Add a One field to the main table, calculated, = 1
- Modify the portal relationship to include the condition One = DisplayMe.
At midnight run a script that
- Finds all records having DisplayMe = 1
- Sorts them by creationDateStamp descending
- Goes to the first record, omits 1000 records
- Replaces the DisplayMe on the remaining records with 0.
Early in the morning, you will see 1000 records in your portal. During the day, as new records are eventually created, you will see them, too. Next day the whole repeats and you restart with the last 1000 records displayed.
If you implement this you will have no speed penalty.