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.

-Becky

How about a calculation field (either unstored or global) =

"Billable"

Comment,

Forgive me but I don't understand. Could you please elaborate a bit?

Thanks,

Becky

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.

Warning with the unstored, if you have to go backwards over the relationship i.e. from billable items back to your main table, it wont work.

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

True, though i just thought i would point it out.