Right after posting, I found that this calculation works:
If ( EvaluationError ( Lookup ( TO::FieldName ) ) = 103 ; “unrelated” ; “related” )
1. Why does this calculation succeed where the calculation in my original post fails?
2. Is there a more elegant calculation that serves the same purpose?
3. I’ve never used the Lookup function before, and some quick research makes it seem pretty irrelevant. Why would I ever use Lookup instead of simply referencing a related field?
I've never used the Lookup function myself for the reasons that you state. This might be the first case where a possible use even exists as opposed to the simpler alternatives.
But a simple Get ( LayoutTableName ) will return the name of the TO that is your current context.
For anyone who stumbles onto this problem in the future:
I discovered a strange limitation of my solution, above. It doesn’t work in the event that the current context is the TO table occurrence! I have no idea why this would be the case.
The only way I found to fix this limitation is to address it specifically. The following calculation will return 1 if TO::FieldName is related, and 0 if it is not.
Let ( [
ERR = EvaluationError ( Lookup ( TO::FieldName ) ) ;
TO = GetValue ( Substitute ( GetFieldName ( TO::FieldName ) ; "::" ; ¶ ) ; 1 )
] ; // End Let Definitions
ERR = 0 ; 1 ;
ERR = 103 and Exact ( Get ( LayoutTableName ) ; TO ) ; 1 ;
) // End Case
) // End Let
The current context in a script is ALWAYS the TO of the current layout. Get ( LayoutTableName ) should always return the name of the TO specified in Layout Setup | Show Records From for whatever layout is "current" at that point in your script's execution and that will always be your "context" determining how calculations will evaluate.
But that kinda makes sense that you would get an evaluation error when you try to look up data from the same TO that is currently your context since the function is trying to use a relationship (which does not exist in that specific context) to access data.
As always, thanks for your response Phil. :)
I understand and agree. It’s just very hard to craft clear and unambiguous language on this stuff sometimes. :)