Performing Find on table through portal

[Ben Parks]

Here's my layout: I have a main Layout/db of prospective clients called Prospects with main table of prospective clients called Prospects in the Relationships graph. I have a tabbed display and on one of those tabs is Contact History. That tab has a portal showing data from a ContactHistory table. This has a few fields including one included for which employee contacted them. What I'm trying to do is find a way under each "Prospective Client" record to be able to filter the contact history table by employee. I've set up buttons to do this. Every time I try to do this, it filters the main prospective clients table, not the encompassed client history table. I don't care if it's done through buttons or a tabbed view showing multiple filtered tables.

Any thoughts?

[Colin Keefe]

To clarify: you want to be able to select an employee and have the portal on the Prospect record show only contact history for the Prospect involving that employee?

[Ben Parks]

That's right. I have multiple buttons: Ben Mike Jeff etc... and Show All. I want to be able to select any of those and have it just show the Contact History for the selected employee within that client, but not have it affect the shown set of prospective clients.

[comment]

You need to filter the relationship, not perform another find. A portal always shows all related records, regardless of their found status.

[Ben Parks]

That led me to find a very simple tutorial on how to do such a thing, and I'm rollin'! Thanks!

Ok... I spoke too soon. I have the filtering working perfectly. But I can't get it to go back to "Show All" on the filtered portal. How can I reset it back to show everything again?

Edited February 6, 2009 by Guest

[Ben Parks]

I don't know if I lost my crowd since I edited my last post, but my problem is not quite resolved yet. The filtering works per employee, but I'd like to be able to UN-filter it as well, so that it shows all Contact History, too. I'm currently using a pop-up menu to select which employee is shown, but even with a null entry, it's still filtering (which is Mr. Obvious, I know).

I came across this demo: http://www.nightwing.com.au/FileMaker/demos8/demo804.html

Which uses Calculation fields to do exactly what I'm looking for, but I couldn't seem to get it to work just right. He also has it set up where the data is within the current table only (albeit, an instance of it) and uses a typed-in search parameter, which I don't want. Any thoughts?

[bcooney]

One way is to have a separate Show All button. This button sets the field that is filtering the portal to a carriage return list of all the EmployeeIDs.

I'm assuming that the popup is based on a value list of EmployeeID and Name, and just showing the second value (their full name).

[Ben Parks]

One way is to have a separate Show All button. This button sets the field that is filtering the portal to a carriage return list of all the EmployeeIDs.

I'm assuming that the popup is based on a value list of EmployeeID and Name, and just showing the second value (their full name).

It's actually referencing a typed (carriage return) value list of their names at the moment, without the EmployeeIDs. I have made a Show All button, but I can't seem to get it to work. How would I set that up? (I know how to get the pop-up to reference a database list of employees with IDs. Where would I take it from there?)

[comment]

There are several ways to do this. If you are using a popup menu, then it would be probably most convenient to add a calculation field in ContactHistory (result is Text) =

EmployeeID & "¶ Show All"

and use this both for the relationship and for the value list.

[bcooney]

Well, if you're not using IDs, then your Show All button would use Set Field to populate the filter field with the value list of Employees.

Something like:

Set Field (gFilter), valuelistitems (get(filename), "Employees")

[bcooney]

This method, though, requires you to have a "hidden" filter field. The popup isn't really what is filtering the portal. The popup drives the calculated global. So, if popup says "Bob" then gFilter is "Bob", but if it says "Show All" then gFilter is the value list. Right?

[comment]

The popup isn't really what is filtering the portal.

Why not?

[bcooney]

How does selecting Show All result in "unfiltering" the portal? Bear with me, M., ...it's been a long day.

[comment]

There you go, B. ;)

Filter.fp7.zip

[bcooney]

Duh, they all have "Show All". Of course, thanks. Love the extra space before Show All so it lists first.

Edit: I know why mine was more complicated--I use IDs under the popup, and hide IDs in value list.

Edited February 7, 2009 by Guest

[comment]

Yours (or rather Søren's) would be more suitable with a checkbox.

[Søren Dyhr]

According to Boyce/Codd could keyfields be treated a little more relaxed when speaking of redundancy, but the secondary key is going to be stored indexed and all. But the actual value is stored in each of the keyfields then without exception ... with say 1000 records does this not show much up as extra storage requirement - but with say 40000, must other fields in the solution be attempted "de-indexed"

The reason why it although not should be discarded is that no refreshing issues exists. While a calc'field on the primary key can't be a unstord calc' but have to be set by a Set Field[ to behave fully in accordance with expectations. But script triggers have now made this a bygone as issue - often have developers stumbled over the problem to let calc'fields monitor changes in other calc'fields a relation or more way.

--sd