I have the same problem. FME Flow 2024.2 Build 24783 - win64

It doesn’t seem to be limited to the MS SQL reader:

47	2025-9-2 11:04:28 | Using Multi Reader with keyword `MULTI_READER' to read multiple datasets
48	2025-9-2 11:04:29 | Creating reader for format: Microsoft Access
49	2025-9-2 11:04:29 | Trying to find a DYNAMIC plugin for reader named `MDB_ADO'
50	2025-9-2 11:04:29 | Microsoft Access Reader: Read 5 DEF line(s). Found 120 attribute(s)
51	2025-9-2 11:04:29 | Microsoft Access Reader: Opening `....accdb' for read operation
52	2025-9-2 11:04:29 | Using MultiWriter with keyword `PRIMARY_DEST' to output data (ID_ATTRIBUTE is `multi_writer_id')
53	2025-9-2 11:04:29 | Writer output will be ordered by value of multi_writer_id
54	2025-9-2 11:04:29 | FME Configuration: Using FME Reprojection Engine
55	2025-9-2 11:04:29 | Loaded module 'XMLTemplaterFactory' from file 'C:\Program Files\FMEFlow\Server\fme\plugins/XMLTemplaterFactory.dll'
56	2025-9-2 11:04:29 | FME API version of module 'XMLTemplaterFactory' matches current internal version (4.0 20240212)
57	2025-9-2 11:04:29 | Microsoft Access Reader: Now reading features from table MetMan_T, 10 record(s) at a time
58	2025-9-2 11:04:29 | Microsoft Access Reader: An internal error has occurred. Please visit http://www.safe.com/support
59	2025-9-2 11:04:29 | Microsoft Access Reader: Failed to parse datetime, attribute set as null

This problem will show up from time to time for me. One time it was so bad that the server ran out of storage space and crashed, too many and too big logs.

What usually solves it for me is to republish the workbench but the important part here is to reupload the connection that's messing up. FME will uncheck it be default since it’s already uploaded.

I just “fixed” this job so now it’s
 

EDIT: This only works sometimes, I don’t know why

I had another problem last year where FME failed to parse dates and crashed. So it wasn’t this exact issue but maybe it can give a hint as to why this happens.

That problem ONLY occured whenever the job was put in a queue. So if someone here has a job that sometimes works fine and sometimes it doesn’t, maybe take a look at if it ran on time or if it was put in a queue.

Very interesting findings - So the way FME Server works is the engine will run and process several jobs before it restarts - this removes a lot of the overhead for starting a new process every time. 

For intermittent behaviour on FME Server it could be the engine is somehow loading conflicting binaries, or is failing to load a binary.

 https://docs.safe.com/fme/html/FME-Flow/ReferenceManual/ConfigFileRef.htm

In the fmeFlowConfig.txt file you can change how frequently the engine will restart. By default it looks to be set to 100 (MAX_TRANSACTION_RESULT_SUCCESSES) and 10 for failures (MAX_TRANSACTION_RESULT_FAILURES)

When you say that it happens when the jobs are in the same queue this suggests that the issue is engine related - assuming the same engine is used. 
 

Here in this post the user shares a log file where sonstigen similar looks to be happening. ​​On the right we have the logfile where all the libs/dlls are imported suggesting the first run of the engine and on the left those libs/dlls are already imported and so are skipped.

What OS are you using?

I’ve found that on Windows Server 2019 there is a limit to the amount of dlls which can be imported. But this usually results in random jobs failing. Here we tend to have a specific format failing which is a bit different.


I would suggest to try and reduce the number of MAX_TRANSACTION_RESULT_SUCCESSES to something like 10 to see it if still happens. If​ it does then you can try setting it to 1. This will mean your engines will restart all the time and add overhead, however, it will could be really helpful to help identify this as the issue. 

​​​​

The queue-related problems that I talked about happened last year. I think we ran Windows 2022 and FME 2024.0.1 at that point.
When we had Windows 2019 we had problemes with dll-files not loading, so I remember tweaking the parameters that you speak of. But as far as I remember those problems went away with Windos 2022.

Last year I had to process four years of travel data. The volume of data made it impossible to handle at once, so I had to run it a day at the time. So I would then make a script to queue up multiple jobs at the time, like a whole month (so 28-31 jobs). That would work fine, I even queued up like a 100 to be run at night.

But as long as something else ended up in queue that wasn’t this script it would crash.

Anyway. I don’t know if this is even related or if it’s been patched out be now. I just thought I’d mention it.

This problem will show up from time to time for me. One time it was so bad that the server ran out of storage space and crashed, too many and too big logs.

 

What usually solves it for me is to republish the workbench but the important part here is to reupload the connection that's messing up. FME will uncheck it be default since it’s already uploaded.

I just “fixed” this job so now it’s
 

EDIT: This only works sometimes, I don’t know why

That didn’t help :(

I feel like a quack doctor here, but sometimes you have to repeat the process a few times…

Also, that screenshot looks good to me(?)

I only see 2 warnings.

Each of the 42000 warnings logs the error “Failed to parse datetime, attribute set as null” / “An internal error has occurred,” which means that in this job run, the MSSQL_ADO Reader may not have loaded correctly.

When I set MAX_TRANSACTION_RESULT_SUCCESSES=10, the error still occurs, but when I use MAX_TRANSACTION_RESULT_SUCCESSES=1, it no longer occurs.

Windows Server 2022 Standard