Hi Guys,

 

I have built relational crm package. I have thousands of contacts and each contact can have multiple addresses which are stored in a related file. On a print layout, I want to display the current address without the use of a portal/filter as it messes my clean layout, so I think I can fairly easily achieve this by creating calculated fields in the contacts table using executesql to bring in only the current address or email addresses etc.

 

My question is, if I introduce calculated fields (they would be unstored), is the calculation triggered only if I have that field on a layout I am using or go into the backend, or is the field always on and calculating in the background. I'm trying avoid the latter case as it would make the db terribly in efficient.

 

Many thanks

 

Jalz

Why use a calculation field? If there is only one “current address” per contact, store its ID as an attribute of the contact and display the related address field(s).

Hi Eos,

 

I have more than 1 address for the contact (usually two, but potentially 3). However I have a primary address field which indicates that correspondence should go there. However I need to do this with other parts of the system as printing related data in FileMaker is pain (wish you could do calculations without resorting to a field just on layouts, without a web viewer)

 

Anyway, are calculated fields always calculating or do they only calculate when called upon, i.e. used in layout?

An unstored calculation field evaluates only when needed.

 

 

As noted by eos, if a contact can have only one primary address, then the primary address ID is an attribute of contact.

 

 

I want to display the current address without the use of a portal/filter as it messes my clean layout,

 

Not sure how this "messes your layout": a portal can be invisible.

Is this print layout going to be showing the primary address from one contact or multiple contacts? If multiple, then you'll notice a slowdown as FM fetches the related address data for each record.