Skip to main content

Hi all,

I’m encountering an issue with the InlineQuerier transformer in FME Form 2024.2.1 (pre-production environment) that seems to differ from previous behavior.(FME Form 2024.1.3 in developement environment)

🔧 Workspace Setup:

The InlineQuerier has two input ports:

tubes (can sometimes receive no features)

parametre_generique (always receives data)


I’m using this request :


❗️ Problem:

When no data arrives at the tube input port, the transformer throws the following errors:

InlineQuerier_2 (InlineQueryFactory): Generating output 'tubes_statuts_inactifs' using query 'SELECT * FROM "tubes"

WHERE (

    UPPER("statut_administratif") NOT IN (

        SELECT TRIM(UPPER(value))

        FROM "parametre_generique",

             json_each(

                 '7"' || REPLACE("valeur_parametre_text", '|', '","') || '"]'

             )

        WHERE code_parametre = 'STATUT_ADMINISTRATIF_RETENU_TUBES'

    )

    OR

    UPPER("statut_operationnel") NOT IN (

        SELECT TRIM(UPPER(value))

        FROM "parametre_generique",

             json_each(

                 '_"' || REPLACE("valeur_parametre_text", '|', '","') || '"]'

             )

        WHERE code_parametre = 'STATUT_OPERATIONNEL_RETENU_TUBES'

    )

);'

SQLite Reader: Opening `C:\Users\ADMINI~1\AppData\Local\Temp\2\wbrun_1754489245451_4360\fmetmp_2\_inlinequery_1754555895273_11956.db' for read operation

Database query 'SELECT * FROM "tubes"

WHERE (

    UPPER("statut_administratif") NOT IN (

        SELECT TRIM(UPPER(value))

        FROM "parametre_generique",

             json_each(

                 'o"' || REPLACE("valeur_parametre_text", '|', '","') || '"]'

             )

        WHERE code_parametre = 'STATUT_ADMINISTRATIF_RETENU_TUBES'

    )

    OR

    UPPER("statut_operationnel") NOT IN (

        SELECT TRIM(UPPER(value))

        FROM "parametre_generique",

             json_each(

                 'e"' || REPLACE("valeur_parametre_text", '|', '","') || '"]'

             )

        WHERE code_parametre = 'STATUT_OPERATIONNEL_RETENU_TUBES'

    )

);' failed. SQLite3 Engine error: 'no such table: tubes'

An error has occurred. Check the logfile above for details

InlineQuerier_2 (InlineQueryFactory): Wrote 0 features to output 'tubes_statuts_inactifs'

InlineQuerier_2 (InlineQueryFactory): An error has occurred. Check the logfile above for details

InlineQuerier_2 (InlineQueryFactory): Database was unable to execute query for output named 'tubes_statuts_inactifs'

SQLite Reader: Closing `C:\Users\ADMINI~1\AppData\Local\Temp\2\wbrun_1754489245451_4360\fmetmp_2\_inlinequery_1754555895273_11956.db' . Read operation complete

An error has occurred. Check the logfile above for details

Translation FAILED with 4 error(s) and 1 warning(s) (0 feature(s) output)

FME Session Duration: 2.1 seconds. (CPU: 1.3s user, 0.5s system)

END - ProcessID: 11956, peak process memory usage: 203756 kB, current process memory usage: 189332 kB

Program Terminating

Translation FAILED.

 

This results in the translation failing completely, rather than just returning an empty result set.

⚠️ Notes:

The tubes port is connected, just sometimes receives no features.

In previous versions of FME (e.g., 2024.1.3), the InlineQuerier would log the error but the translation would continue — now it fails entirely.

🧩 Question:

Has anyone else encountered this behavior in FME 2024.2.1?

Is this change documented anywhere?

What is the best practice for handling optional/empty input streams in the InlineQuerier under this version?


Thanks in advance !

Hi ​@sbnikkou 

I tried a sample workspace and tested it in 2024.2.1 and newer versions and while I noticed the preview looked different between FME versions, the translation continued for whether or not I get a  'no such table:...’ InlineQuerier error

For example, this is my workspace:

And while I get the same error for older and newer versions, the translation seems to continue and my data still gets written out by the FeatureWriter.

Is this maybe the same behavior you were hoping for or are you experiencing something different? If you are experiencing something different, would you be willing to share a similar sample workspace? 🙂


As a potential workaround: try the NoFeaturesTester custom transformer from the Hub and connect it between the table that sometimes has data and the InlineQuerier. You may need to add some bogus attributes too.


Hi ​@desiree_at_safe Thanks for your Answer, 

This is a similar workspace sample in both versions :

 

 

It’s true that data will still be written even in the second case, but the translation fails just after ): and in my original workspace (witch is way larger) this causes job failure mid translation and doesn’t pass other transformers properly !

It is bizzare how this is not documented anywhere !

___

Best, sbnikkou


I’ve used the NoFeaturesTester before sending items to the InlineQuerier. Confirms at least one record enters the input port(s). I also like using the FeatureMerger and set the Requester and Supplier both to: 1 if you need a basic join/merger function. 


Hi ​@sbnikkou

I’m sorry this change unexpectedly impacted your workflow and is now causing wider job failure issues! I’m investigating this issue further with team to see if we need to reconsider this change and/or consider ways we can better communicate this to users!

I’m not sure about your particular workflow, but ​@redgeographics and ​@mmccart’s suggested workaround is a great option. With the NoFeaturesTester set before the InlineQuerier, you can redirect the data so you don’t run into the Translation Error that entirely stops the process. It might require some restructuring of your workflow, so let me know if it works for you!

Thank you for bringing this up!

 

hINTERNAL REFERENCE: FMEENGINE-82915]


Hi ​@mmccart , ​@redgeographics and ​@desiree_at_safe ,

Thank you all for your responses.

I was able to get my workspace running successfully on FME 2024.2.1 using the NoFeaturesTester, as suggested, as a workaround.

I’ve included a screenshot of a sample workspace showing how it works in both scenarios: when data arrives at the port and when it does not.

Best, sbnikkou 


Hi ​@sbnikkou 

I wanted to let you know I’ve tested your issue in 2025.1 and it looks like the InlineQuerier returns to the pre-FME 2024.2 behavior you noticed. The translation continues even with the ‘no such table.. error thrown. 

I again apologize for any confusion or disruption to your workflow! The team is still investigating this change, but I figured I’d let you know in case you’d rather use that newer version without having to need a workaround! 🙂


!INTERNAL NOTE: FMEENGINE-87763]


Reply