Say I have a portal on a layout in my "Main" file listing the related casenotes from the "Casenote" file. I have some field on the layout below the portal that are also from the Casenote file.

My goal is when I click on a row in the portal, it will update the fields below to show the information of that portal row. Below is an image of what I'm trying to accomplish.

If I click on a record by A, then the fields by B should change to whatever the values from the record in A are.

You need :

a global 'g_record_Id' in the related file

a text field 't_temp' in the Main file

a relationship MainFile:t_Temp::Related:Record_Id.

A script <set global> in the related file

SetField (g_Record_ld, record_Id)

Then, in your portal, use a button (or row) with script attached

GoToRelatedRecord (show- your portal relationship)

Perform External Script <set global>

SetField(t_Temp::PortalRelationship:g_Record_Id)

Now all the data in your "B" would come from relationship Main:t_Temp::Related:Record_Id

Hi ddreese,

The fields below your portal will need to be based upon a 1:1 relationship with your Main db.

Create one new global text field (gRelatedID) in your Main db and use the script step:

Set Field [gRelatedID, Related::YourUniqueRelatedID)]

Create a new relationship joining gRelatedID and Related::RelatedID. Place your lower fields (based upon this new relationship) below your portal. They won't need to actually be in a portal because they will always be a one-to-one.

Now place a transparent rectangle over your original portal row with the script attached and disallow entry into fields.

When you change rows in your upper portal, the lower fields will also change to that current record.

LaRetta

OK,

There are quite no difference from the 2 methods, except that using a global would not be as accurate when moving from record to record in this Main file.The global would keep it's value and the datas in B would not necessarily be related to the data in A, except if you clear that global when moving to another record.

Now, this could also be done with a classic relationship and not necessarily with a constant 1:1.

HTH

Hi Ugo,

You are correct that the global should be blanked. It is really no problem to add that step as you know. Just add to any exit layout scripts (or main navigation buttons), Set Field [gRelatedID, ""].

As for basing this on a classic relationship - well, what is your definition of 'classic'? Is a classic relationship 1:n or also 1:1? Whatever you call it, this solution certainly isn't a constant relationship.

I'm a bit surprised that you would suggest using a global as a key in a related file. Did you test your solution? I have a sample file if anyone is interested; however, this solution is quite easy and I doubt anyone would need it.

LaRetta

Don't be surprised...

You know I LOVE globals.

I never used the SetField (t_Temp,::Related:Record_Id) before.

This clear some steps from the scripts I'm actually using in all my solutions (which are working perfectly BTW).

Strange noone never pointed this to me as I surely made about 10-15 answers for just the same querry.

As using a text field clear one more script step, I therefore would go for an intermediate solution from both our posts.

SetField (t_Temp, ::Related:Record_Id).

Thanks again.

Hi,

Like you Ugo, I love globals but I see that I can tend to overuse them. Because they apply to every record in the db (and the db can be quite large) it uses more resources than necessary. In this case, all we need to do is relate to only one record in Main not all records and not between records (which is where globals shine).

So, in this particular instance, I agree with you that setting a regular text field with the Related::UniqueID would be more resource-efficient.

Cheers,

LaRetta

Hi everyone,

In addition to being more efficient (using a text field instead of a global), it would eliminate the problem of the same record displaying when switching to another record because it could only display if it was related and in this solution, only one record would ever be related. I would, nonetheless, clean up behind myself by deleting the text field contents.

However, if this technique is used in multi-user environments, I still would use a global so that each User's selected field could be different (local). And then include a Set Field step to blank the global as indicated in the previous post.

I've attached a simple demo in case anyone is interested. Form1 addresses the specific original post by ddreese and is structured as 'A' and 'B' (although my field names are different. Sorry, I cheated and used an existing related skeleton db). Form 2 shows using a portal with only the names down the left side. The remainder of the layout can be devoted to the detail information.

This would decrease some problems with portal pop (when editing record details), because once a record was selected from the portal row, that record

LaRetta said:

Because they (global fields) apply to every record in the db (and the db can be quite large) it uses more resources than necessary.

Hi LaRetta, just one small comment:

Globals are stored only once in an single place in the file, so they use less space than standard fields.

IOW their values are not stored for every existing record, in fact they are outside of the record data block structure and they can have valid values even if db contains no records at all.

Also it is much easier to clear a global field than standard (record) based field.

Dj

Thanks everyone for your comments, I had they theory worked out in my head, but I never thought of the transparent button idea!

The difference between one standard text field holding an ID or a global holding that same ID is negligible. It was a generalised and sloppy comment and I appreciate you catching it. And ohhhh so true about not needing to 'find' a global (to clear it or use it) - because globals are always there! Thanks!

I'm taking the demo down for some cosmetic surgery and a few additions. I'll repost when I'm satisfied with it.

LaRetta

Hi all,

Another method would be to replicate the layout in the casenotes file, and run everything from there. (from your screenshot example, there seems to be no need for the "Main" file for this operation)

Your portal would be from a one to many self relationship based on a global that would define your related records/ filter the portal (eg' g_Category::t_Category)

Then, all you would need would be a button on the portal row that would go to related record(g_Category::t_category). Determining which method was better would depend on your filtering criteria.

Just a thought.

-Raz

How would you add a next and previous record buttons? I have been using Ugo's intermediate solution for several reasons. As an answer to my own question, here is what I have been using:

Freeze Window

Go to related record [show, Original Relationship]

Go to related record [Related File::Unique Related ID]

Perform Script [sub-scripts, external: "Related File"] --- Next record script

Set Field [RelatedID, Related File::gRelated ID]

Refresh Window[]

Next record script in the related file:

Go to Record/Request/Page[Exit after last, Next]

Set Field ["gRelated ID", Unique Related ID]

Is this the fastest/best way to do it?

I have a problem when this script is run when there are no related records. It will go through all the "un"-related records.

I would also like to keep the navigation field, Related ID, out of the main file. The reason is that I have a "last modified" field in the main record. It will update to now when running these scripts to view the next related record.

Scott

You can test for the existence of related records before performing the subscript, e.g.

If [Related File|Unique ID::constant]

Go to Related Record [Related File|Unique ID]

Perform Script [external]

End If

I am still working on the Next & Previous record buttons for records in a portal. My method above works provided the portal is not sorted. But when it is sorted, next and previous are not as they appear in the portal. I have tried adding a sort to the related file's scripts, but that causes the next and previous buttons to not work at all.

Aparently "Go to related record [show, Original Relationship] " does not sort the records according to sort in the relationship.

Any suggestions would be appreciated.

You're correct. It doesn't sort the records, but it does go to the first related record based on the sort. What if you set the current portal row minus/plus one (depending on next/previous status) in a global, go to the related records, perform an external sort, then go to record based on the related global field, and set the gRelatedID with the id of that record?

My apologies! I forgot that I was going to re-post the demo.

I got side-tracked on solving portal-pop (in new and exciting ways) at the same time and everyone knows how that one goes! And then I got side-tracked on fixed portals, portal navigation techniques, displaying found sets in portals and .. and ...! Ahhh well, it's an easy solution that I've written out in (my usual) detailed style so a demo probably isn't necessary anyway. If anyone asks, I'll do it, though.

LaRetta

Portal-pop? Please, elaborate on that one, if you will. I'm intrigued.

Hi Queue,

Portal-pop is the irritating phenomenon of, for instance, viewing many records in a portal and you

Ah, yes, I see. And I don't like fixed portals much because they take too long to navigate compared to using the normal scrollbar, in my opinion at least. Thanks for the elaboration though.

Thank you Queue. I was headed in the right direction, but when I could not get it to work I abandonded the idea.

It seems like so many steps for such a small thing to do!

Scott

Hi LaRetta,

Could you please re-post your solution file for Portal Record Navigation?

thanks

Hi djlane,

Okay, you asked so here it is. This demo is certainly not pretty. It's purpose is to allow viewing more detail on one specific portal than will easily show in a portal row, as requested in the original post in this thread.

It would work nicely for large comment fields or to display additional data from a portal record. It currently uses a text field to trap the portal record ID. I would suggest instead using a global for this purpose, in which case you would need to control all navigation to other layouts (see Form 2) and also navigation between records. You would need to hide the Status Area. All navigation controls would need to include a script step to Set Field [scriptTemp_txt, ""] or blank it before moving anywhere - if you use a global field.

The current demo would work fine if not multi-user. I suggest that anyone viewing this demo first read the entire thread to see why it was created, and what it's limitations may be.

LaRetta

PortalNavigation.zip