Not sure which forum Tabs, Scripts or Portals is best but I think here....

I'm using a tab panel with tabs A and B

Tab A is a form view for the records

Tab B is a portal of those same records .. which in essence gives me a list view

I'd like to click on portal row, say 6 for this example, and go to object tab A record #6,

click on portal row 4 and go to object tab A record #4, etc.....

I started with:

Go to Portal Row [select; No Dialog; Get ( ActivePortalRowNumber )]

Go to Object tab A ..... easy enough

Then what ??

Or am I totally off base?

Tab B is a portal of those same records ..

What exactly is the relationship behind the portal?

Sorry ... I always forget something important.

I just related it back to the original table based on a global field....

Postage::AA (Text ; Global) Autoenter = "A"

Named it Postage 2

Portal Setup:

show related records from : postage 2

Here's one way:

Go to Related Record [ from: Postage 2; using: current layout ]

Go to Object [ "tab A" ]

---

BTW, your description of the relationship makes no sense to me, but least we know it's a self-join...

Edited September 2, 201114 yr by comment

I had tried that but used:

Go to Related Record [ from: Postage; using: current layout ]

.....instead.

Thanks.

---

BTW, your description of the relationship makes no sense to me, but least we know it's a self-join...

OK .... so how about it's a self-join based on a totally useless field called AA (technically cOne) that has an auto-enter value of "A"

You don't need the additional fields. Simply self join on the key field using an "x" join (cartesian).

Typically, a selection portal and form are side by side. It keeps the user aware of where they are in the list. The portal row is typically highlighted, as well.

Yes but I was trying to .. and accomplished... getting a 'List View' of all records in the table on one of the tabs instead of another layout.

Maybe there's another way, or better way, but it's all I could come up with.

I don't have a key field really because that would limit records shown in the portal to only those matching ... correct? Using the global text field the portal always shows all records (which are later deleted after printing postage and new records are imported)

Yes but I was trying to .. and accomplished... getting a 'List View' of all records in the table on one of the tabs instead of another layout.

This can be terribly slow when the record counts get high and the portal is sorted... the whole data set for the sort field needs to be brought down from the server to the client. It can also cause record locking issues.

Read up on cartesian joins. The point I was trying to make is that is important, imho, to help the user establish a footing in the data. Where are they? Let the interface help them. I think switching tabs is confusing and disruptive.

Record lock, Vaughan? I'm not seeing where that'll come up. Please elaborate.

It used to be that the first related record in the portal gets locked with the parent record is open. This may have changed in later versions... I'm happy to be corrected. :)

Hmm. That's one for Todd Geist, Vaughan. I think that is no longer the case. Have you watched his DevCon video? It's an excellent, in-depth analysis of Commit.

It used to be that the first related record in the portal gets locked with the parent record is open.

I don't think that was ever the case.

Simply self join on the key field using an "x" join (cartesian).

I don't have a key field really because that would limit records shown in the portal to only those matching ... correct? Using the global text field the portal always shows all records (which are later deleted after printing postage and new records are imported)

Just to clarify ... Cartesian Product join can use any two fields except for summary or container. The two fields do not need to relate nor do they need to have data in them. So join date to number using 'x' if you wish, Cabinetman, and do away with the unnecessary join field; all records will relate. :laugh2:

Cartesian ...... I was just following something based on a file I had set up for me long ago V5. I wasn't really familiar with it. Thanks.

Tabs ..... The user basically doesn't need to work with the data here and list view is the primary view.

Records are limited to only those being printed ....at the moment.... so it wont slow down.

This is just for the rare occasion 1 needs to be edited. But personally I like the Tabs a lot...

Server .... Initial plans are for a single user Runtime on a local machine

Finally ... Guys I'm just someone with no training who needed to create a database back in '96 and started with FMP v3.

In '04 I started selling books online and FM was the natural choice. I don't always know how to describe what I'm doing

or use the correct terminology so I apologize but just cut me a little slack.... I'm NOT a trained programmer but I think I've done pretty good

...... with your help!