Skip to main content
Solved

InlineQuerier Fails When One Input Port Receives No Data in FME Form 2024.2.1

  • August 7, 2025
  • 9 replies
  • 345 views
sbnikkou
Contributor
Forum|alt.badge.img+3

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(

Β  Β  Β  Β  Β  Β  Β  Β  Β '["' || 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(

Β  Β  Β  Β  Β  Β  Β  Β  Β '["' || 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'

Β  Β  )

);' 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 !

Best answer by redgeographics

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.

    This post is closed to further activity.
    It may be an old question, an answered question, an implemented idea, or a notification-only post.
    Please check post dates before relying on any information in a question or answer.
    For follow-up or related questions, please post a new question or idea.
    If there is a genuine update to be made, please contact us and request that the post is reopened.

    9 replies

    desiree_at_safe
    Safer
    Forum|alt.badge.img+20

    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? πŸ™‚

    Happy FME-ing!
    redgeographics
    VIP
    Forum|alt.badge.img+62

    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.

    FME rocks! \m/
      sbnikkou
      Contributor
      Forum|alt.badge.img+3
      • sbnikkouContributor
      • Author
      • Contributor
      • August 18, 2025

      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

      mmccart
      Enthusiast
      Forum|alt.badge.img+29
      • mmccartEnthusiast
      • Enthusiast
      • August 18, 2025

      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.Β 

        desiree_at_safe
        Safer
        Forum|alt.badge.img+20

        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!

        Β 

        [INTERNAL REFERENCE: FMEENGINE-82915]

        Happy FME-ing!
          sbnikkou
          Contributor
          Forum|alt.badge.img+3
          • sbnikkouContributor
          • Author
          • Contributor
          • August 20, 2025

          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Β 

            desiree_at_safe
            Safer
            Forum|alt.badge.img+20

            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]

            Happy FME-ing!
              atdvf
              Contributor
              Forum|alt.badge.img+1
              • atdvfContributor
              • Contributor
              • September 8, 2025

              Hi all.
              Another idea would be to use the first version of InlineQuerier, which doesn’t have this problem (actually I’ve never encountered any problems).
              I attach a FME 2021 workspace with only the first version of InlineQuerier. You can open it in another FME Form session, copy the transformer and paste it into the workspace you are developing.

              Greetings from Switzerland

              Fabrizio

                desiree_at_safe
                Safer
                Forum|alt.badge.img+20

                As an update on this issue

                Happy to share that this has been fixed! The InlineQuerier will now create the table even when no features are received on an input port, so it will no longer fail with a "no such table" error.

                Please install version 2026.1 or newer at FME Downloads - FME by Safe Software

                Β 

                [Internal: FMEENGINE-87763 / FMEENGINE-88831]

                Happy FME-ing!

                Community Stats

                32,623
                Posts
                123,818
                Replies
                40,988
                Members
                Terms & ConditionsAccessibility statement
                A product of
                Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.