In the same layout? Is the relationship for the portal a "self join" relationship? (Records in portal and records in layout come from same data-source table)
Otherwise I don't see how an "account activity" record could be displayed in the same layout--a script using Go To Related Records can pull up this record in a different layout based on the account activity table--but not the same layout unless the records come from the same table.
Your description of what you want to do is a bit vague in filemaker terms.
Do you want to select an "activity" portal row and see the full related record in the same layout?
Do you want to select an "activity" portal row and list all the other "accounts" that this row is related to?
Both of these are possible via a second portal. I usually set a global field in a table of global display keys as my secondary portal key.
Using these Global Display Keys allows you to cascade portals drilling to more detailed information.
You build relationships in Manage|Database|Relationships between table occurances of your data and the Global Display Keys table.
Then select your the table occurance as the table for your portal. then its just a matter of setting the Global Display Key fields that are part of the relationship and the data displays in your second portal.
Phil > No the tables are not self join. It is: Accounts Table (kp_accountsId -> kf_accountsId) Activity Table
Aammondd > I am sorry for the confusion. What I want to do is: in Accounts layout, I have a portal displaying bunch of activity related to that perticular account. And when I click on one of the record row, I want to display more details about that perticular record (maybe right below the portal).
Is that possible?
Ok, add another relationship to your system:
Accounts::gSelectedActivityID = SelectedActivity::ActivityID
gSelectedActivityID should be a field with global storage enabled.
ActivityID should be an auto-entered serial number defined in the Activity table.
SelectedActivity is a new table occurrence of Activity created by selecting Activity and then clicking the button with two green plus signs.
Now a very simple script can be attached to a button in your portal row:
Set Field [Accounts::gSelectedActivityID ; Activity::ActivityID]
You can then place the fields from SelectedActivity on your layout wherever you need them and they will update to show the details from the selected activity. You can also use Accounts::gSelectedActivityID = Activity::ActivityID in a conditional format expression on your portal row fields to change the fill or text color to provide a visual indicator as to which portal row was clicked to bring up the selected Activity details.
Phil describes what I suggested My only suggestion is that rather than placing the fields from the second table occurance you use a portal only to ensure that anything you might want to related to those fields will be evaluated in context of the relationship easily, and it gets you familiar with working with portals.
I think Phil didnt mention that you need to add the global field to the accounts table. (technically the global field can be anywhere even in its own table but that adds some relationship and other issues to properly display the items. Phils method is simpler for a new person to handle)
I don't think putting defining the global field in any other table will work unless you use a filtered portal technique instead of using it in the portal's relationship.
Also, since this is displaying data from only one selected record, I do not see any advantage to using a portal for it. That will not affect how anything evaluates unless there is a portal filter involved--something that I did not suggest here.
Thus my comment about yours being simpler.
There isnt really any advantage except being able to select all the fields you want when using the portal tool (and the nice little enclosing box :) )
But learning to use portals is one of the things people seem to have trouble with the more exposure to them the better.
I will add however that knowing when you dont need a portal is equally as important.( In this case you do not need a portal.)
Im sorry for the delayed post. The global field method really worked!!
Well, Phil, I am still learning on how to use and work with Portal so it is just a super help to be able to talk and ask you guys for help.
I trully appreciate for all you guys help!!
THANK YOU VERY MUCH!!