Hi,
since some (sub)versions easymorph tries much much more often to interprate an integer as a date and then e.g. in exports it leads to errors and problems.
I also do not like this function in Excel and now it is also here 
.
Yes - I can set the column to "no format" or the "1000" format for every column in every file - but I do not want/cannot change many fields in many old jobs.
Is there a way to deactivate it globaly or is there a change to get the "old" behavoir?
best wishes
Peter
The "new" behavior preserves formatting more consistently, but otherwise, it's very much like the "old" behavior.
We can add a general setting available in any action to disable format auto-detection (as below) in that particular action:
How does that look to you?
Thanks for your suggestion - that could help for new jobs, but for existing jobs (where the detection changed), it would be helpful to disable it for the whole job on one point gobal. So that we do not have to check every single action.
best wishes
Peter
Yes please enact a global disable auto format. We have hundreds of easymorphs on the server. We wouldn't want to go in and fix each action. See below for an example.
@Justin_Grewe, just to clarify, the example in your screenshot reflects the usual behavior in that sense that the recent changes didn't affect this particular behavior. If it worked previously, it will keep working as it used to.
I am unsure when/if this started happening or if it was there from the start. All I am asking for is a global feature to turn it off on every action. In the C# or F# code whatever it is, if we can just assume all is general format if this flag is turned on in the Easymorph. Still will be a pain to have to go through each EasyMorph and turn that setting on, but will be better than going to every action. I don't think there is ever a case where we need formatting done automatically for us on any column we have really.
@dgudkov there I cannot agree. Since some updates ago (sorry I do not remember which version it was and it was sometimes only noticed later) there was a change and existing jobs that had not changed for years stopped working, so that we have to adjust them (field by field).
Mainly mysql inserts/updates had a problem when trying to save an original integer field, which was now automatically recognized as a date in easymorph, into an integer field in the database.
best wishes
Peter
@riegler-eConsulting I was referring to the particular case in the screenshot above. In that case, the format was already saved in the column and therefore the behavior didn't change.
Previously, auto-detected column formats could be silently saved unbeknown to the user, as if the formatting was explicitly selected by the user. While it worked smoothly in some cases, it was confusing in other cases. In the latest release, we've changed the logic to make it more deterministic and predictable. Now, saved auto-detected date formats have less priority than those selected explicitly by the user or returned by the data source. So the precedence is as follows:
Unfortunately, this was a breaking change (about which we warned in the respective Release Notes) and required manual workflow adjustments after migrating to the newer version. I understand it caused inconvenience as workflows could start failing after migration. Unfortunately, there was no way how to improve the handling of formatting without breaking changes at all. The good news is that formatting behaves deterministically now.
We never have saved the format of a data on that column. Why would we want a date on a number field describing last month counts. All of these columns except for 3MonthsAgo are all integers describing count of sales. I don't understand why EasyMorph needs to convert any formats automatically. Can we not just have a raw setting where it doesn't do any of this auto-formatting? If I needed formatting I would make the TSQL do it before it got to EasyMorph.
Thanks.
