Match portal to found set?

[Ockham]

I am developing a project management database in FMP7 that has several hundred projects being tracked. After a good deal of interface design sessions we settled on a primary layout whereby a portal on one side of the layout lists all of the projects and the remainder of the layout contains the detailed fields for the project selected from the list.

This is accomplished with a Table Occurrence of the main Project Table related back to the main Project Table where an auto-entered serial field with a constant value of "1" is the key relationship field so that all projects are listed at all times in the portal. A related record script button overlaying each listed name changes the rest of the screen to match the selection.

This approach has been successful with end users in our beta tests but for one issue. When a user creates a found set by, for example, searching for all bridge projects, only the 30 or so bridge projects are found but the portal still displays ALL of the project files. This behavior can be confusing for our end users who are expecting that the portal list will instead be reduced to their search term.

The preferred behavior is for the user to perform their find request, receive a found set of records, and have the portal match that found set. I was thinking of a script to search both tables at once but I am thinking that this is prone to problems considering that any number of 20 or so fields can be a search field at any time.

I am wondering if anyone has any ideas on how to make a portal dynamically reduce itself to match the current found set to accomplish this.

Thanks

[Fenton]

A portals is controlled by its relationship, and relationships have little to do with found sets, especially found sets in other tables.

But you can "capture" that found set, by copying all the unique IDs of those projects (they do have unique IDs?), using the Copy All Records script step on a layout with only the ID. Then Paste into a global text field. Use that global as the left-hand side of the relationship, back to the real ID.

The Copy All Records should be in a subscript, because it should [x] Run with full access privileges. Copy All Records requires Export privileges, which might be Off for some people. Doing it this way will allow it to work for them, without compromising your security otherwise.

The Find must be scripted, obviously. You should provide a global field(s) for searching. Then use that to set your Find criteria in the table with the data.

I just happen to have a handy-dandy example file here (that I forgot about :-)

CAR.zip

[NFD]

Thanks Fenton, I'm able to use your solution as well.

Depending on the extent of the search criteria Ockhams users need, an alternative may be to use Soren Dhyr's technique to allow users to set/select values in Global fields in the header of your portal to both display variably constrained lists of records in the portal AND go to the corresponding records using a scripted GRR. When global field(s) are empty, ALL records appear in the portal.

See thread;

http://www.fmforums.com/threads/showflat.php?Cat=0&Number=142643&an=0&page=0#142643

[Ockham]

That worked beautifully Fenton, thank you very much. I had been experimenting with something along the lines of scripting a Find/Replace All step into a number placeholder field which changed from 0 to 1 after the Find had executed and then basing my relationship on that number field. It worked but was running at glacial speeds even for a small amount of records.

Using the Copy All Record/Requests into a global field is a nice clean way of doing it and much less prone to error. To implement it, I only needed to add a global search field and change the relationships between the TO and the original Table.

NFD, I use something similar to Soren's technique on a few of the other portals where I am filtering the portal data. But what I am trying to do here is match the current found set in my Table to a portal of a Table Occurrence of the same Table. Fenton's technique works great.

Thank you again for all all of the suggestions and solutions. Hopefully I can return the favor someday.