Jump to content

Permenantly filter portal records


This topic is 5651 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Good morning!

I have a database with 2 layouts. They are similar but differ in a few ways. One is a service call ticket with a portal showing billable activities and the other is a service call ticket showing non-billible activities.

The relationship is one TICKET, many ACTIVITIES. The primary key is TICKET_NO in the TICKET table and the foreign key is TICKET_NO in the ACTIVITIES table. Each ACTIVITY record also has a field called TYPE where the valid entries are BILLABLE and NON-BILLABLE.

I have built my relationship via TICKET_NO and TYPE. I have a global field in the TICKET table where I can either choose BILLABLE or NON-BILLABLE. The portal dynamically filters the results depending on which choice I have made in the global field. This works just great.

Now for the problem, and really it's not so much a problem but more of a question on how other Filemaker developers accomplish this:

I would like one layout to always show BILLABLE lines and the other layout to always show NON-BILLABLE lines. No user interaction required at all.

I have built this already by creating two more global fields in my TICKETS table and having a startup script that populates both fields; one with BILLABLE and the other with NON-BILLABLE.

This works but is this the right way to do it? I don't want to depend on Filemaker's ability to remember a value entered in a global field the last time it was closed in single user mode because it seems like as the developer, I could easily lose that value if I'm not really careful. On the other hand I also don't particularly care for the script that runs on file open because I know that if a file opens via a relationship the script won't run.

I'm just looking for some more dependable options.


Link to comment
Share on other sites

Oh good lord the lightbulb just went on! Of course I know that Filemaker has calculated fields but I had no idea that they could global too. This is the perfect answer! It should work everytime.

Thank you Comment! How did I miss this obvious feature for all these years? It's pretty embarrasing.

Link to comment
Share on other sites

That is a good point. Although I doubt you would actually create a layout based on the billable/non-billable TO's, so it would probably never come up. And it was the same way before, using a global field to switch between the two.

I actually prefer another method, with the calculations residing in the Child table, in the form of:

Case ( Status ; ParentID )

so the relationship is:

Parent::ParentID = Child::cConditionalParentID

Link to comment
Share on other sites

This topic is 5651 days old. Please don't post here. Open a new topic instead.

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

  • Create New...

Important Information

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