Skip 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.

Calculation results read as field names (instead of text values)

Featured Replies

Hi,

I wonder if I can calculate a "shortcut" in one of my calc fields. Currently, I'm using this expression to get certain field values, based on the field Category:

  • Case (
    Category = "Person" ; BAS_PER::LemmaPER ;
    Category = "Organization" ; BAS_ORG::LemmaORG ;
    Category = "Geographic" ; BAS_GEO::LemmaGEO ;
    ... )

Instead of using the Case function I'd rather calculate the name of the result field like


  • "BAS_" & Left ( Category ; 3 ) & "::Lemma" & Left ( Category ; 3 )

(I'm ignoring UpperCase here to make the function easier to read.)

The result I get unfortunately is

[color:red]"BAS_GEO::LemmaGEO[color:red]" and not BAS_GEO::LemmaGEO ,

so, what I want as field name is treated as text.

Is there a way to have Filemaker read my result as field name? (Using FMA 9)

Thanks a lot

: Mike

Check out the GetField() and Evaluate() functions.

BTW, one cannot help wondering why all your lemmas aren't in a single table.

  • Author

Hey Mike,

Thank you for pointing out the right direction. This is how my calculation now looks like:

  • Let (
    CatAbbr = Upper ( Left ( Base::Category; 3 ) ) ;
    GetField ( "BAS_" & CatAbbr & "::Lemma" & CatAbbr )
    )

(CatAbbr = Category Abbreviation) (And, as you see, I put the Upper function in there.) Replacing GetField with Evaluate gives the same result.

BTW, one cannot help wondering why all your lemmas aren't in a single table.

This is because of the database structure. The information common to all records is stored in a single big Base table (BAS), with relationships to other tables based on "category" of data that hold the other pieces of information. E.g. the Persons table (PER) holds fields like Prename, Surname, Title; fields that are not needed in other tables. So, one database entry actually consists of two records, one in BAS, and one in PER / ORG / GEO / ...

The reason behind this is that I want to allow users to create relationships between entries of different categories, e.g. organization – person.

So far, this structure has worked fine, but I admit, it makes some things go definitely slower. This can be seen e.g. in particular in filtered portals.

The only alternative I can see is putting everything in one table, using self-join relationships in order to relate different records to each other. Hm. Suggestions welcome.

Thanks again!

Well, I don't mean to delve too deep into this - it just seems strange that a common field (it is a common field, isn't it?) needs three variations.

  • Author

No, not really.

For example, in the case of an organization the field content of LemmaORG is what the user keys in.

But in the case of a person LemmaPER is a calc field:

LemmaPER = PrenameBindingPER & " " & SurnameBindingPER.

I don't mean to delve too deep into this

: Am actually preparing a new thread on this, as mentioned: Some filtered portals are too slow for my taste.

Create an account or sign in to comment

Important Information

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

Account

Navigation

Search

Search

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.