What you can do here is set up another relationship between the two tables, based on a global field in the parent table. Capture the key field value of the portal row that's clicked and set the global field to that value.
Mike's reply is spot on...I use this same method.
But he left out the warning...
Hitting the portal row button sets the global field, linking to your related table and showing the details..all well and good.
But when you leave that record, the global is still set. Going to another record will maintain the same (now inappropriate) details.
Set script triggers in appropriate places (On record load, etc.) to clear the value in the global field to avoid this.
Following up with what Mike said you can use that other relationship for creating related records as well as isolating a specific portal record.
I have a demo http://www.pueblo-systems.com/CreateRecords.zip
Or - warning about the warning - set up the relationship to be based on two fields:
The global field (as previosly described)
And the parent ID field.
So when you move to the next record, as in the example, the record selected by global will NOT be displayed.
Filed in the category of "Why didn't I think of that?"
I'll update my own solutions for this as well. Thanks!
But be sure you are aware of the difference. You may have to guard against creating duplicate record IDs in the auto-create record side.
sounds good; Did you mean it as I implemented it that the relation checks if the parent table flobal field with the cateched id is equal to the id of the portal row A N D that the parent table id equals the portal row parent id - as it happens to be present in a 1:n-relationship in the portal table?
what do you mean with that?
Both of you: great small discussion that evokes and answers some questions that would occur anyway. That's why the forum is so valuable because you folks are really engaged! Thanks again.
I can't speak for Bruce but he might referring to what I suggested using the same relationship to create the related record and isolate specific ones.
As far as your relationships are concerned. This is predicated on the child table having a unique primary key field.
the relationship to dislpay a specific portal row would simply be.
parentTable|gPortalRowKey = childTable|PrimaryKey
When you click on the portal row you set gPortalRowKey with the Primary Key of the child record.
If you check the box 'allow creation of records in this table via this relationship' on the child side. You can use the same relationship to create the portal records.
99.999% percent of the time i use this method. I find it's easier for users to click a button instead of having to scroll down to the 'New Portal' row.
Hope this helps
You do not need a separate relationship
parse the row primary_key_id to a global, via the row button script
create a second instance of the portal as one row, to display additional fields of the select row
define a filter on the single row , g_pk_id = REL::pk_id
The downside is a refresh flush is required on the script to force display update
Like what PSI suggests but no need for an additional relationship in the rel graph
I think this solution was already mentioned in the beginning, second posting, by Mike. And it lacks a check whether you have changed e.g. the row in the parent table. The still the - now - wrong detail information would be displayed. Therefore Bruce introduced a second parameter in the relation where the id f the parent table has to equal the parent_table_id in the portal table data row. As it is a 1:n-relationship this is is present there.
Hope to have wrapped that up correctly.
this is a very helpful link to this topic. Maybe more complete than we could have discussed it here though everthing here was very valable to me anyway! Great ressouce that should be less "hidden" on the side...