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.

Featured Replies

  • Newbies

I have an extensive database of about 4000 names and addresses of patients. I am trying to figure out a way to list all the duplicate addresses on the list- I sometimes see the entire family as patients and don't want to send out mailers to everyone in the same household.

I also see a number of pediatric patients. Is there a fast and easy way to both identify these patients and be able to send a letter to the parents, using the parents name?

Your assistance would be appreciated.

Searching for "!" in a field will show all records that have duplicates for that field.

I'm not clear on how you identify which records are children from the information you mention.

It sounds like you might benefit from a little more data normalization, maybe a new "household" table that connected a family together.

Check out this discussion:

http://www.fmforums.com/threads/showflat.php?Number=107924

You can easily condense your address labels by using a Sub-Summary by FamilyID part for your address labels, but this depends on having a database structure that defines a family with something like a Family table.

How do you currently know whether different people are part of the same family?

  • 1 month later...

re: "Searching for "!" in a field will show all records that have duplicates for that field."

Yes, but how do you get a list containing one and only one record from each family? (assuming you have something identifying each family uniquely)

You either use a subsummary part as Ender described or you create a self-relationship based on the field (or a calculated concatenation of the fields) that determines uniqueness. Then you create a calculated field of serial = selfrelationship::serial. Perform a find for 1 in this field and you will have a unique set containing the first record for each family.

Queue,

re: " Then you create a calculated field of serial = selfrelationship::serial. Perform a find for 1 in this field and you will have a unique set containing the first record for each family."

I must be missing something obvious, but why does that only identify the first record of each family? Isn't the relationship also true for other records of the same family?

thanks

Relationship::field refers to the first related record according to the sort order defined for the relationship. If no sort order is defined, it is equivalent to the first created record that matches the relationship criteria. So serial = selfrelationship::serial is only true for the first record in the file that meets the criteria for selfrelationship. Any duplicates found afterward will have a serial that is different than selfrelationship::serial, the serial for the first related record in the file.

thanks for the excellent description.

Does the "calculated field of serial = selfrelationship::serial" result update dynamically, for every new found set, or do you have to force a recalc every time?

E.g., if the calc result is fixed, the member flagged with the 1 may not be present in a later found set, unless you recalc the serial field...

In fact, when FM decides to dynamically update fields and when not (lookups, relations, calcs etc.) is one of the more frustrating element of learning to set things up, IMHO...

It's a calculation based on a relationship. Therefore, it cannot be stored and is always dynamic.

Calculations involving globals and related values can never be stored. So you can rest assured that such types are always updating. Lookups are only updated when a Relookup is performed or the key field for a lookup is modified or set with itself (i.e. Set Field [field, field]). Auto-enter calculations are only performed at the time of record creation or when data they rely on is first entered, and maintain their value unless manually modified. Unstored calculations (forcibly set when no global or related field is referenced) automatically update. Calculations involving Status functions *must* be set to unstored, or they will not auto-update.

Does that help some?

You bet. ;-)

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.