Curious incident using SQL Server - huge log file as a result

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

EDIT2: This post is most likely wrong

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

I’m back. I just encountered this bug again, so lets document it.

Just like the first post in this thread I’m getting thousands of warning

We are currently running FME 2025.1.2. Windows 2022.

The reader that’s acting up is “Microsoft SQL Server (MSSQL)” or just “SQLSERVER”.

If I run the workspace by itself on FME Flow it works. But if I queue up another job before it (not the same workspace) I get null dates.
The other workspace that I queued up first had a ArcSDE-readers instead of a normal SQL-reader. I don’t know if that’s relevant or not, but I thought I’d mention it if someone else wants wants to try and replicate the bug.

Right now I don’t know how to get around this problem in a clean way. I guess I’ll try the solution from the post above.
MAX_TRANSACTION_RESULT_SUCCESSES=1
But I’d rather find a better solution since this is an option that needs to be set again and again every time that we upgrade FME.

I wanted to see if I could easily reproduce this bug and I wanted to see if the type of reader mattered. When I first encountered this bug I tried the normal SQL-reader but also the JDBC and a SQLCreator. But it didn’t matter (if I remember correctly).

So, three workspaces

1. A ArcSDE reader that’s reading one table. Nothing else
2. A MSSQL reader that’s reading one table and a tester to check for null values
3. A workspace that submits both of them to FME FLow, since the first job only took ~6sec and the order matters. 

If #2 i run on its own it works.

But when it ends up in queue behind #1 the datetime fields return null value and the script terminates.

So yes, I can easily reproduce it.

Then I switched the MSSQL reader in #2 for the JDBC version and to my surprise it worked!
So maybe I’ll try using that in my real script and we’ll see. I’m not sure if this will really solve the problem, but it’s worth a shot.

Changing the OS locale to English finally solved the problem.