Integer format made automatically as date

Hi,
this is not a real bug but maybe you could fix it in a next release.
Often when I import a database table (from postgresql) in which the first column is an “Id” with integer data type, the result table made its format as a date.

Today i was put in my project a simple Parameter to Table action and same problem occurred. I think that integers that start from 25570 (e.g. linux date 1970 Jan 01) are automatically recognized as date.

Hello @carlo.nigro ,

click on the column (in the example: user_to_check) and then change the view format from the combobox in the top bar of EasyMorph.

It’s only the visualization in EM.

Hi AndreaM and thanks for answered my issue.
I know that I can change the format, but I would rather that by default the numbers had no format.
In fact, often the wrong format is inherited between the actions making it inconvenient to go and modify it :slight_smile:

Hi @dgudkov,
sorry I’m quoting you because I noticed that this issue can be a problem when someone like me schedule an automation.

Last three night I found this error.

Then when I opened my project and launched it, data seemed all ok… but when I tried to change some elements in the flow, the format of the id field changed automatically from “No format”:

immagine

to “dd-MMM-yyyy”:

immagine

So when I start last “Export to Salesforce” action shown, the underlying field is not considered but the formatted data.

Thanks for support.

Hi @carlo.nigro !

I am not @dgudkov , but I can try to answer your question. In EasyMorph, there is a distinction between the ‘display format’ and the ‘real data representation’. The ‘display format’ refers to how the data is shown in the EasyMorph Desktop app / workflow view, while the ‘real data representation’ refers to the actual value of the data.

EasyMorph doesn’t have a specific ‘Date’ type. Instead, all dates are internally stored as numbers in what is called the OAdate format. This format represents a date as a floating-point number, where the integral component represents the number of days before or after midnight on December 30, 1899, and the fractional component represents the time on that day divided by 24.

So, if your target system (Salesforce in this case) requires a specific input date format, you can use the ‘Modify column(s)’ action in EasyMorph along with the format function:
https://help.easymorph.com/doku.php?id=syntax:functions:format

In your case, you can try to use something like the following formula in the ‘Modify column(s)’ action:

format([Date as number],'yyyy-MM-dd hh:mm')

image

Update

Apologies, @carlo.nigro, I misinterpreted your message earlier… To clarify, you want the column to explicitly stay the number, not the date? In this case, you could try instead of ‘No format’ pick explicit number format for your invoice_doc... column, like

Hi @olysak and thanks for reply!
My problem is a bit more complicate and I will try to explain it better.
As I shown in the first table, mi column Invoice_Doc originally is a database id (integer). So if I store it in Salesforce using directly EasyMorph interface, all works correcly.
But if I change column format (as happens during my nigtly scheduled process), last action does not use the stored number placed behind the column but the front formatted number, so Salesforce raise correctly an Exception.

Could you please try specifying the column format explicitly by selecting ‘1000’ from the dropdown list, as shown in my previous screenshot? You mentioned that changing the column format caused the Invoice_Doc format to change. However, it’s not clear why this format changes at all, as this should not happen automatically unless you select the ‘No format’ option

Ok now I changed the format to ‘1000’.
I will check results of the night schedulation and on monday I will reply to you with updates :crossed_fingers:

Hi @olysak,
unfortunately I have the same problem… although I have set the field with the format ‘1000’ I still have this error.

But if I open the project and run it with it in front of me, the error doesn’t occur :frowning: