A list view, a table view and a portal may all be used to list records from a table. That table can be a table defined in the current file or it may be a table defined in a different file if an external data source reference has been defined in Manage | external data sources and a table occurrence using that external data source reference to specify this table has been added to Manage | Database | Relationships.
That's easier to set up than it sounds.
Go to Manage | Database | Relationships
Click the far bottom left button to create a new table occurrence "box".
From the drop down in the dialog that appears, select "Add FileMaker Data Source".
Select first the other file, then the table within that file as the data source table for this new table occurrence.
You can now link this table occurrence to others in your relationship graph--which will be needed if you insist on using a portal--just as though your external table were defined in the local table.
Note: the fact that the table is defined in a different file is not sufficient reason by itself to use a portal. A portal may be your best design option, but what you have described so far does not make that case.
Thanks Phil. This is what I have done and now have a refresh issue with the portal view.
I have created a single-record file (dashboard) called Job_Listing with a portal that links to the Job_File mentioned above via a relationship where a global field in the Job_Listing file matches a number field in the Job_File - both simply contain the number 1. The relationship is defined within the Job_Listing File
This works fine and suits the layout purpose. Clicking on a portal listing item, for example, takes me to the actual job file. The portal view is filtered using the following calculation, If(JobFile::FilterCalc=1;1;0).
The filter calc, stored in the Job_file is, If(Status ≠ "closed" and Asignee = Get ( AccountName );1;0).
In another file I have a basic to do list and using a button with an assigned script this enables me to create a job file from a to do list item. The script works fine and on checking a table view of the Job_File all the calculations are properly executed etc, including the filter cal.
However, when I click on a tab to take me back to the Job_Listing view the recent job doesn't show. If I take the portal layout into Layout mode then into browse mode it refreshes. The tab has a refresh window script assigned to it.
Any help appreciated.
Why do you need the added complication of a single-record file? Why not set up this table and relationship in the same file as the other table?
If(Status ≠ "closed" and Asignee = Get ( AccountName );1;0)
can be simplified to:
Status ≠ "closed" and Asignee = Get ( AccountName )
to produce the same result as you now get.
Instead of Refresh Window, use Refresh Window [Flush cached join results]
But a simple way to remove the update issue whether you use one file or two, is to use match fields instead of a portal filter. The match fields on the Dashboard side of such a relationship can be:
constClosed--a calculation field that always returns the text "closed".
cAccountName--an Unstored calculation field using Get ( AccountName )
But if you are using this to limit a user's access to only records that are assigned to them, this method still allows others to see records that are not assigned to them once they have brought up some records from the Job File. They can perform a find or just do Show All Records to see other records unless you have taken additional steps to prevent that.
A much more secure and simpler set up method is to use Record Level Access Control set up in Manage | Security. See "Editing record access privileges" in FileMaker Help and check out this particular sub section: "Entering a formula for limiting access on a record-by-record basis" for a description of how to set this up.