Jump to content
MariaAux

Display Find Results in a Portal

Recommended Posts

MariaAux    0

Hi There,

I did a google search to learn more about displaying find results in a portal i.e. perform a find and only those resluts should be displayed within a portal and I found a couple of ideas. One was the concept of multi-key fields but I noticed the video was done with an older version of Filemaker. With FM 11, we have the ability to do a filter within a portal based on a calcualtion and I wonder whether there isn't an easier way now with FM11 to use this portal filter functionality to produce a portal with only the find results?

Is Multi-keys still the best way or is there a better way with Portal filters?

Thanks so much for your advice and time.

Maria

Share this post


Link to post
Share on other sites
Fitch    148

A portal filter doesn't have any "awareness" of the found set, so it can't really help you there. A multi-key field seems like the way to do it.

Share this post


Link to post
Share on other sites
dansmith65    83

Why do you want to display find results in a portal? What's wrong with displaying them in list view?

Share this post


Link to post
Share on other sites
LaRetta    477

Is Multi-keys still the best way or is there a better way with Portal filters?

Hi Maria,

It is usually best to use relational filter instead of portal filter because portal filters have to evaluate all records before constraiining the results. This is great stress on your system when you have a lot of records. And since either way, you would need to collect the IDs of the record-set, it is best to use multi-line (global or calculation) in new relationship to the portal. Check out this thread for gathering IDs from a found set: http://fmforums.com/forum/topic/61394-found-set/page__hl__agn%C3%A8s__fromsearch__1

Hi Dan,

Sometimes it helps (when viewing a form layout of multiple records) to see a portal on the side of those same records. It acts as an visual index and can allow click-jumping to specific records within the found set. :)

Share this post


Link to post
Share on other sites
BruceR    152

I would qualify that statement about portal filters; you can do both.

If the potential set of unfiltered records is large, then the relationship should be designed as the first filter. Portal filtering can then be used as a secondary filter.

The portal filter calculation will operate on the entire record set of values presented by the relationship. The portal filter calc operates on these records strictly in creation order, independent of how the relationship definition or portal definition sorts them.

Share this post


Link to post
Share on other sites
LaRetta    477

Thanks, Bruce. Yes, many times we further portal-filter a relationally filtered relationship. Whew! That was a bite-full!

The portal filter calc operates on these records strictly in creation order, independent of how the relationship definition or portal definition sorts them.

I did not know this! I thought this was interesting but wait ... it would not really matter since all of the related records must be walked through by the filter anyway, would it? Where might knowing that sorts are ignored by portal filters, be important? After all, we are talking about filtering and not calculating, right? Thanks for stepping in.

Share this post


Link to post
Share on other sites
BruceR    152

Depends on what you are trying to do with the filter calc.

For instance, assume a sorted relationship to a people table, sorted by last name; where the relation uses a global field to match on City.

Set the filter field to "Seattle". Say there are 2000 Seattle people; 75 whose last names begin with "A".

Have a script that sets variable $$names to empty and then does a refresh.

The portal filter uses this calc:

Let( $$names = List( $$names; People::LastName); Left( People::LastName; 1) = "A")

What will the portal show?

(Only the 75 Seattle people whose last names start with "A"; sorted by last name).

What will $$names contain?

(The list of all 2000 Seattle last names; unsorted.)

Share this post


Link to post
Share on other sites
BruceR    152

Or consider this variation for the filter calc:

case( Left( People::LastName; 1) = "A";

Let( $$names = List( $$names; People::LastName); 1)

)

Now $$names contains the list of Seattle last names beginning with "A"; but it is unsorted.

If instead you collected the record ID values into the variable, you might have assumed it represented a sorted list. But it won't.

Share this post


Link to post
Share on other sites
MariaAux    0

Thank you all so much for your invlauable advice. Got me where I wanted to be! Thanks a million

Share this post


Link to post
Share on other sites
dansmith65    83

Hi Dan, Sometimes it helps (when viewing a form layout of multiple records) to see a portal on the side of those same records. It acts as an visual index and can allow click-jumping to specific records within the found set. :)

I'd never heard of this interface technique before; sounds interesting. I couldn't see any practial use of displaying find results in a portal, so thanks for pointing this out.

Now you got my gears turning though... This could possibly be an alternative to using a filtered portal. It would take a lot more work on the developers end, but it would allow for greater flexability for the users 'filters'.

The portal filter calculation will operate on the entire record set of values presented by the relationship. The portal filter calc operates on these records strictly in creation order, independent of how the relationship definition or portal definition sorts them.

Interesting detail. like LaRetta, I failed to see the relevance of this at first, but your examples were interesting. I can see how this aspect of the portal filter could possibly be levereged for some cool custom feature.

Share this post


Link to post
Share on other sites
Morenomdz    1

Kinda reviving an old topic but I found this intresting. I have a layout that show work orders on the left, on a portal that filter by the work order status, on the right it shows the whole record that is selected on the left portal. All good.

I also have a list layout simple because the search found most of the time contain many records and my users like to visualize all the records and find the one they need, as they usualy dont have the very exact work order ID when they need to use the search, so, using the same layout design that filters the work orders by status, but filtering to show only the found set records is actualy very usefull.

Many records found showing on a list on the left, and the whole record showing all the fields on the right.

 

Share this post


Link to post
Share on other sites
Mark Scott    60

Hey Morenomdz,

Wasn't sure if you had a question there (seemingly not), but your revival of the thread provides a great opportunity to point out that, since the time of the original thread, there have been some significant advances in the area of "Master-Detail" (portal-plus-detail) layouts. See, for example, Todd Geist's Master-Detail and Master-Detail 2.0 techniques at Modular FileMaker, which build upon Bruce's Virtual List technique.

(Also reminds me that it's been a while since I last checked to see what's new at Modular FileMaker—I notice that Dan Smith's got a recent entry—so I guess I know what I'm going to be doing this morning.)

hth,

Mark

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Similar Content

    • By TJ53
      I guess people are using a similar technique for creating and editing portal records after the new FM16 card window feature, any posts or links about this?
      In any case, this is how I'm doing it (sample attached) ... any feedback appreciated!
      Create or edit portal records.fmp12
    • By wedgeman
      So i'm dealing with two tables.
       
      1.  VisitTable.
      2. GraphicsTable
       
      in a VisitTable layout, i have one or two portals related to the GraphicsTable, each related by a different factor.  One portal would be related by a Date field, the other would be a ClientName field..
      My desire is to click on a thumbnail in either one of these portals, and have that selected image be displayed in a separate/larger image window (which could be a container field in the current table, Or another portal?  I don't care how - i just need to have it show up) 
      I don't know the best method for doing this (ie., click thumbnail to have image fillin a separate location).  In this particular instance, I don't want this to be a separate window, but to display in a container field view on the current window/layout. 
       
      how do I accomplish this?
      thx
       
       

    • By wedgeman
      Table 1 (Visits) is a clinic visit table, with numerous fields of data.
      Table 2 (Prescriptions) is a related table for prescriptions given on a particular visit. Table2 is related to Table1 by fkey  - - -    T1ID.
      Table 3 (Patient) is a patient table (contacts).  PatientID is the identifier for Patient and is related in Visits,Prescriptions, and Patient
      I need to have (in a Visits layout) a portal (self-related by PatientID), which shows a list of previous visits to the clinic by this patient.
      On this portal I need to show any (1 or many) Prescriptions (from Prescriptions table) which would've been given during that particular Visit
      So it's in essence a need to show 2 foreign tables (1 being a self-view by PatientID and the other being the Prescriptions but filtered by PatientID
      I have been unable to figure out a good method for this.
      My only thought has been to give up on working *IN* Visits, but creating a separate table ("Combiner"), and in Combiner, hold all Visits and Prescription data.
      Could I also have a Combiner table that's simply an active "calculation" table, where these two tables are 'looked up' on an as-needed basis, combined, and fed into Visits via a portal? (so it's not actually held data, but is looked up as needed)
      what's the preferred method?
    • By Rachel
      This is my first time posting, and I apologize if this is the wrong place. I've only been filemakering for a few months, so again, apologies if this is a stupid problem.
      I could use some advice.   I'm working on a solution that must create monthly reports in the following form:   http://i.imgur.com/Cf4Fjic.png   I've given up trying to bend the summary fields to my will, and began using the following approach:   Make two new tables - Queries and Reports.   In queries table, I have fields for M1, M2, M3, Region, Category, Subcategory and four result fields (M1, M2, M3 and YTD.) I also have foreign key into the reports table.   Then in reports table, I portal into the Queries table.   When report is run, a bunch of queries in queries table are created. The Results are populated via ExecuteSQL expressions.   My question is mainly this: Is this too backwards? I feel like maybe this is too weird of an approach and I"m just missing something simple about reporting and creating summaries?

      Thanks!  
    • By NewBoard
      I currently have a form that contains a portal. In the portal there is a value that will either be "Accepted" or "Rejected". I'm wondering if there's a way to parse through this table to check if any related values have a "Rejected" or if they are all "Accepted". Then using that outcome, decide if the form should display Rejected or Accepted.
      Please let me know if I need to provide any more information and/or images.
      Thanks in advance for any assistance you can offer!
×

Important Information

By using this site, you agree to our Terms of Use.