Skip to main content
Solved

InlineQuerier documentation update or logic change

  • April 1, 2026
  • 4 replies
  • 61 views
phil.l.avista
Contributor
Forum|alt.badge.img+1

InlineQuerier documentation states: 

 

The InlineQuerier creates a temporary SQLite database, and creates a table for each input object that is connected to it. 

 

This is not always true. If an incoming flow is empty, the table is not created. This should be stated clearly in the documentation. I would prefer that the table is created anyway. The transformer will fail otherwise. Related question: InlineQuerier Fails When One Input Port Receives No Data in FME Form 2024.2.1 | Community

Edit: Tested in FME 2025.1.3

Best answer by david_r

I just tested this with FME 2026.2, the behavior looks as I would expect. If a table referenced in a join is empty (no input features), the InlineQuerier is still able to to execute the join, leaving the joined attributes as missing:

An inner join will not return anything, as expected.

There are no errors or warnings in the translation log.

Interesting note: If I disconnect the connection to “input_b”, the attribute “data_b” is not <missing>, but not present at all.

    4 replies

    hkingsbury
    Celebrity
    Forum|alt.badge.img+70
    • hkingsburyCelebrity
    • Celebrity
    • April 2, 2026

    What is your use case for needing the blank table to be created?

    In the event of no feature reaching the port, could you use a NoFeaturesTester to provide one?

      david_r
      Celebrity
      • david_rCelebrity
      • April 2, 2026

      Having looked at the use case in the related question, I would agree with OP. If you use e.g. a JOIN in the InlineQuerier and one of the tables doesn’t exist, it will fail the entire workspace rather than just return no features, which I think would be the expected behavior, at least from people coming from a database background.

      Using the NoFeaturesTester is certainly possible, but seems like it shouldn’t be necessary.

      ​@phil.l.avista Try reproducing the issue with the latest FME version and see if it has already been improved upon. If not, consider opening a support ticket at https://support.safe.com

       

        phil.l.avista
        Contributor
        Forum|alt.badge.img+1
        • phil.l.avistaContributor
        • Author
        • Contributor
        • April 2, 2026

        What is your use case for needing the blank table to be created?

        In the event of no feature reaching the port, could you use a NoFeaturesTester to provide one?

         

        I am using a NoFeaturesTester to overcome this limitation. 

        The custom transformer shouldn’t be necessary because InlineQuerier should conform to SQL spec. In SQL, an empty table is a valid relation, and all relational operators, including joins and SELECT statements, are formally defined to operate over empty relations without error.

        When InlineQuerier defines an internal table and receives zero input features, the SQL‑consistent behavior is to execute the query and return an empty result, rather than raising an error condition. In my case this is expected and downstream logic accounts for this condition. 

         

        david_r
        Celebrity
        • david_rCelebrity
        • Best Answer
        • April 2, 2026

        I just tested this with FME 2026.2, the behavior looks as I would expect. If a table referenced in a join is empty (no input features), the InlineQuerier is still able to to execute the join, leaving the joined attributes as missing:

        An inner join will not return anything, as expected.

        There are no errors or warnings in the translation log.

        Interesting note: If I disconnect the connection to “input_b”, the attribute “data_b” is not <missing>, but not present at all.

        Community Stats

        32,431
        Posts
        123,238
        Replies
        40,557
        Members
        Terms & ConditionsCookie settingsAccessibility 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.