What are lookup enums?

[Deactivated User]

Tech Ref says
LOOKUP_ENUM The enumeration of the lookup value.
That does not tell anything to a non-native English speaker non-techie.

What are enums?
How do the work/function?
How do their value get determined?
Are they for static lookups only?

Martti K.

[Anon Anon]

In this context* "enumeration" just means "the number of"....

another_martink wrote:

What are enums?

So they are just the numeric identifier of the lookup value.

another_martink wrote:

How do the work/function?

They don't really "work" as such, if you choose your lookup to pass back a numeric id rather than a code value, then the "number" will be stored on the database rather than the "code" when you associate the lookup to an attribute

another_martink wrote:

How do their value get determined?

Its up to you when you create the lookup values.

another_martink wrote:

Are they for static lookups only?

Sort-of ; you could of course build a dynamic lookup that returned a numeric value rathen than a code, but I would not think that the same "enumeration" term would be used to describe that (that would just be a "dynamic lookup which returned a number") :unsure:

(* which, even as a native English (only) speaker I don't think its good English! :wacko: )

[Deactivated User]

Thanks Dave.

How do the work/function?

How do their value get determined?

So for the lookup you choose whether you want to use CODE or ENUM as ID
and then based on your selection you enter either code or enum for the ID.

Martti K.


.

[Deactivated User]

If you select LOOKUP_CODE you also enter Lookup_code for the ID of the value.Lookup_enum field values are then all 0.
If you select LOOKUP_ENUM then you enter Lookup_enum as the ID and only numeric entries is accepted. Lookup_code and Lookup_enum have the same values in in the database.

Martti K.


.

[Anon Anon]

^ yes indeed.... so you might well be tempted to just 'always' join against LOOKUP_CODE in any bespoke SQL that you may be writing.... you CAN do this but you need to be aware of a few things;

(Obviously) the LOOKUP_CODE is of character type on the database and LOOK_ENUM is numeric, so if you joined a real numeric value on the database to LOOKUP_CODE (because you have fallen into the above temptation) then you may get "unexpected results" - in that; depending on your database vendor and/or version various error may be thrown in the character to numeric conversion. For example Oracle will auto-cast the char to a number so that will probably work OK, SQL Server insists (I think!) that you cast your columns to the "real" data type or it throws an error. Typically you would hit a problem if you built some code against one database vendor/version (or copied it from somewhere (online?)) and were then trying to deploy that code against a different vendor/version with more strict type-matching.

So.... if you are going to join to LOOKUP_CODE always, then you should get into the habit of casting the columns to the right datatype.... or just make the join to the correct column in the first place (i.e. avoid that "temptation" :tongue )

[Deactivated User]

if you are going to join to LOOKUP_CODE always, then you should get into the habit of casting the columns to the right datatype.

Thanks for pointing that out and reminding

Martti K.

[Anon Anon]

In reports if we use lookup attributes then it will be better to pass the "Enum" as Hidden Key so that it will be simple to pass and fetch the appropriate data from DB.

In Microsoft clarity interface if you have used an look up attribute in msp mapping then to work you need to create that static look up with Hidden Key as LOOKUP_ENUM otherwise it will not work.(This was the case until 12.1).


cheers,
sundar