Jump to content
View in the app

A better way to browse. Learn more.

FMForums.com

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Best practice for address history?

Featured Replies

I am creating an in-house solution where we keep track of (among other things) contacts and am at the moment working on adding functionality for storing address history for our contacts.

 

I will take care of all editing with scripts - my question is about best practice regarding storing and displaying the data.

 

My idea is to:

  1. use a related table and timestamp both creation of a new address and when an address is no longer the "current" address. This would  allow me not only to see previous addresses but to identify which was the current address at a given time.
  2. have a plain field in the layout for displaying the current address.

The question then is:

  • Can I be certain that the plain field on the layout will always show the address that was last input into the system?
  • Would it be better to use a filtered portal?
  • Or should I setup the relation to only give me one record?

We will be using this on a WAN so speed matters.

 

And, yes, the address is stored in more than one field - I am just assuming that this doesn't make the basics of this any different. Please correct me if I'm wrong there.

I'd add a from and thru date to the address record. You could filter on addresses where isempty(thru_date) for the portal or simply sort.

  • Author

I'd add a from and thru date to the address record. You could filter on addresses where isempty(thru_date) for the portal or simply sort.

 

A sorted relationship? Which would then give me the (first or last?) of the related records?

 

Or should I rather use ExecuteSQL?

IMHO, if performance is a concern, you should set up a dedicated relationship to include only current address/es. Which should be quite easy to do, if you define a calculation field in the Addresses table =

Case ( not EndDate ; ContactID )

That said, I haven't actually tested this against a filtered portal speed-wise. If each contact has only a handful of addresses, the difference might be negligible.

For filtered portals, the difference between 5 historical addresses and 50 historical addresses will be noticeable, but not between 1 and 5.

 

But sorting the relationship with no portal would be just fine. I'm not sure if the sorting takes up any more time than the relationship does anyway.

Create an account or sign in to comment

Important Information

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

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.