H_custom_26 field storing different values to Extended Information.H_custom_26

[Berto2002]

I am using custom 26 to store a binary number outcome from some workflow; values such as 11001, 01101 etc.

I realised after testing that the number 01101 is not an integer when custom 26 was stored as 1101...

HOWEVER, I have an email that sends me the contents of each custom field and for fields a-t and 21-30 it shows both the values from the Request and the Extended Information 'versions' of that field and they are DIFFERENT. I have done because I have seen variances in the past and now there's another.

What I mean is that this expression in the email: {{.H_custom_26|empty}} --- {{Extended Information.H_custom_26|empty}} returns two different values: 1101 and 01101 respectively.

In short, the Extended Information.H_custom_26 is storing the full sequence of digits added to the field which includes the preceding zero (01101) but H_custom_26 is truncating (to 1101).

My question is can I rely on the extended information storing the digits (not as an integer) and thus refer to that in my workflow; or do I need to alter my number storage so we never have a preceding zero?

Thanks!

[Steve Giller]

On 21/12/2023 at 09:59, Berto2002 said:

My question is can I rely on the extended information storing the digits (not as an integer) and thus refer to that in my workflow; or do I need to alter my number storage so we never have a preceding zero?

In the schema h_custom_26, regardless of the table, is listed as an Integer field.
If you wish to preserve a leading 0 you must use a Varchar field.