Hi @vki​ ,

Interestingly this came up with another user not too long ago for another customer. In their case, it had something to do with their user profiles so they had to reset them on the machine they were accessing. It's possible this is similar to what you are experiencing as well. Do other users who access the same machine also have this issue? In the other case, the same issue only arose for a set of users so it's possible that a difference in permissions could be causing some conflict with the libraries used by the DateTimeConverter.

Do you have any other builds of FME Desktop on this machine that exhibit the same behaviour or is this the only build of FME you have on this machine? This seems like a rare issue but hopefully we can track down what is causing this!

Hi Chris

Other users have the same problem as well.

We have FME-Desktop installed on two servers, those are the builds (win32 and 64), the problem is the same with all builds.

Server 1

FME(R) 2020.0.2.1 (20200511 - Build 20238 - WIN32)

FME(R) 2021.1.3.0 (20211002 - Build 21631 - WIN32)

Server 2

FME(R) 2018.1.0.2 (20180903 - Build 18547 - WIN32)

FME(R) 2020.0.2.1 (20200511 - Build 20238 - WIN32)

We use a shared FME-Folder on Server 2, therefore the behaviour of the transformer should be the same with all builds.

Thanks, Vera

Can you try launching FME workbench as an administrator (Start menu > Right-click FME Workbench and run as admin) to see if that resolves the issue? This might help us determine whether it could be permissions-related.

As a second troubleshooting step, perhaps try removing the connection to the shared folder to see if that fixes it. Just trying to narrow down the potential issue.

Hi @vki​  and @chrisatsafe​ ,

One of our customers had the same problem, but only with two users on a server, other users didn't.

The problem lead us to the profiles of that two users and after removing the profiles their problem was solved.

Our customer wrote:

Because it only concerned me and my colleague in terms of problems, we have removed my profile on the server1 today. And that has led to a good result, no more red datetime calculator. We were the only two already working on FME2015 on the server 4 years ago, I think there was something old in our profiles. So solved, just reset some settings.

I'll get more information from our customer about what profiles they are using and share it here.

Kind regards,

Krien Guijt

Vicrea Solutions

Hi Chris

Launching it as administrator didn't change anything.

But when I removed the connection to the shared folder, the transformer was ok again.

That doesn't solve my problem though, because we have some custom transformers in that folder and I need this shared folder...

If you navigate to the shared folder, can you look for any .fmx files that may have a naming conflict (for example, DateTimeConverter.fmx). Helpful that we have narrowed it down a bit to the shared folder as it seems something in that directory is causing a conflict.

Have you noticed any other transformers behave like this or is it isolated to the DateTimeConverter?

I navigated to the named folder. There's no naming conflict with any of our custom transformers.

And it's only the dateTimeCalculator, that doesn't work correctly (as far as I know).

This is our shared folder:

Shared FME Folder (D:\\..\\xy\\FME on Server 2)

*******************************

CoordinateSystemExceptions

CoordinateSystemGridOverrides

CoordinateSystems

CsmapTransformationExceptions

Formats

TransformerCategories

Transformers

Workspaces

in the Transformers folder:

config (folder)

dependencies (folder)

AzimuthCalculator.fmx

fmesuite.fmx

GeographicBufferer.fmx

HorizontalAngleCalculator.fmx

+ our custom transformers (.fmx)

the path to the shared folder we use is D:\\..\\xy\\FME (= options in FME), but those folders (Coodinate System...Workspaces) where also in D:\\..\\xy and D:\\..\\xy\\FME\\Transformers, though empty. I deleted those empty folders, but that didn't change anything.

I then searched for the Transformer-Folders on Server 1 and 2. That's what I found. Is that correct?

Server 1

========

c$\\Program Files\\FME\\transformers > empty

c$\\apps\\FME\\transformers:

config (folder)

dependencies (folder)

- AzimuthCalculator.fmx

- fmesuite.fmx

- GeographicBufferer.fmx

- HorizontalAngleCalculator.fmx

Server 2

========

C:\\Program Files\\FME\\transformers

config (folder)

- dependencies (folder)

- AzimuthCalculator.fmx

- fmesuite.fmx

- GeographicBufferer.fmx

- HorizontalAngleCalculator.fmx

c$\\apps\\FME\\transformers: > empty (

Shared FME Folder (D:\\..\\xy\\FME on Server 2)

*******************************

CoordinateSystemExceptions

CoordinateSystemGridOverrides

CoordinateSystems

CsmapTransformationExceptions

Formats

TransformerCategories

Transformers

Workspaces

in the Transformers folder:

config

dependencies

AzimuthCalculator.fmx

fmesuite.fmx

GeographicBufferer.fmx

HorizontalAngleCalculator.fmx

+ our custom transformers (.fmx)

Hi @vki​ and @chrisatsafe​  

Addition from our customer:

We thought it was strange that two colleagues were affected by the error (only on this server) and that I and another colleague were not affected by it. During the consultation about this, we suspected that those who suffered from this error were using an FME Desktop version 2015? had worked.

Me and that other colleague hadn't worked with that desktop version.

Logging out, having the windows user profile removed by a system administrator, and then logging in again proved to be sufficient.

Perhaps removing the entire windows user profile can be prevented by removing only the FME part from the user profile. It is difficult for us to determine which folders FME uses and should therefore be removed.

@chrisatsafe​  Does Save maybe have a solution for that?

Kind regards,

Krien Guijt

Vicrea Solutions

@vki​ I've just converted this thread to a case so our team can investigate further. Additionally, I've spoken with our development team and based on our initial investigation it looks like this is being caused by FME looking in the wrong location.

I've created an issue in our tracking system and linked your case to the new issue. You will be notified as soon as the issue is resolved and I will be sure to update this thread as well. @krien​ - thank you again for sharing your input regarding your customer's fix! As this appears to be the same issue, I've also linked your case to the issue to ensure you are notified as well.

Thank you both for reporting this!

thanks.

Maybe this is of importance:

I lately created a new custom transformer and installed it on Server 2.

But I don't know, since when the transformer doesn't work anymore. Maybe there's no link here...

Hi @vki​ ,

Good news, our development team has been able to reproduce the same issue in house so they can get started on a fix; however, they have a follow-up question if you are able to provide clarification on one point. When you mentioned:

"We use a shared FME-Folder on Server 2, therefore the behaviour of the transformer should be the same with all builds."

Does this mean Server 2 has a Shared FME Path defined that points somewhere within the Server 1 installation, or possibly at a location that contains copies of some of the Server 1 installation?

Hi Chris

All installations on server 1 and 2 point to the same Shared FME Path on server 2.

If you expand my post from 5 days ago (counting from today...), you see the path of our Shared Folder on server 2 (and all the other transformer paths)

Perfect, thanks for pointing that out!

Hi Chris

I just found another transformer that doesn't work properly anymore: the HTTPCaller.

One of our workspaces with this transformer doesn't work anymore.

But it's only with the POST-method, the GET-method is ok.

Here, the problem is also the Shared Folder. As soon as I use the transformer without Shared Folder it works ok.

Thanks

Vera

Hi @vki​ ,

Thanks for pointing that out - this is likely being caused by the same issue but I will be sure to add a note to the issue report that this is also impacting the HTTPCaller so our team can investigate.

Thanks for pointing that out!

Hi all (@vki​ & @krien​:

Our team has implemented a fix for this as of build 22290 (FME 2022.0) which is now available on the beta downloads page.

Hi Chris

Thank you for this fix.

You write, it's as of build 22290. Does this mean, that later versions of FME need to install it too?

If we update to FME 2022, will it be integrated? When will the official version of FME 2022.0 be released?

Correct, any build newer than 22290 will have the fix in it. Our 2022.0 release will be coming soon. If you'd like to be notified when it becomes available, please enter your email in the stay informed form at the bottom of the downloads page.