Skip to main content
Question

FeatureWriter with dynamic table name fails in FME 2025.1.1 (PostgreSQL) – "No valid columns provided"

  • March 11, 2026
  • 2 replies
  • 87 views
jfav
Contributor
Forum|alt.badge.img+1

Hello,

I have a workspace in FME Form that reads a large number of tables from a PostgreSQL database and writes them into another PostgreSQL database with the same schema structure but without data.

Workspace design

I use a FeatureWriter configured for PostgreSQL with the following settings:

  • Table name is dynamic and taken from the incoming feature type:

       Table Name = fme_feature_type

  • Attribute Definition = Automatic

  • The destination database already contains the tables (same structure).

Each feature is therefore written to the corresponding table in the destination database.

Behaviour in FME 2023.2

With FME Form 2023.2, this workflow works perfectly, even though the tables do not all have the same attributes.

Behaviour in FME 2025.1.1

When running the exact same workspace in FME Form 2025.1.1, I now get the following error:

POSTGRES Writer: Cannot write to table 'enu_cad_caracteristique_constructive'. No valid columns provided
Writer failed in write() call
POSTGRES writer: An error has occurred. Check the logfile above for details

My suspicion

It seems that in FME 2025.1.1 the FeatureWriter no longer correctly handles the dynamic attributes, as if the writer does not recognize the incoming attributes when the table name is dynamic.

Question

Has there been a change in the behaviour of FeatureWriter between FME 2023 and FME 2025 regarding dynamic schemas or attributes?

Or is there now an additional parameter required when writing to multiple tables with different attribute structures?

Any guidance would be greatly appreciated.

    2 replies

    nielsgerrits
    VIP
    Forum|alt.badge.img+66

    There were issues with dynamic writing in the earlier versions of FME 2025, but I’m not exactly sure what the corresponding versions were exactly. We are now running 2025.2.1 which works well. If you have the possibility I would install the latest release and see if the issue goes away.

    FeatureReaders FeatureWriters were fixed in 2025.1.2, classic Readers and Writers in 2025.1.3.

    Buckle your seatbelt Dorothy, cause Kansas is going bye-bye...
    jfav
    Contributor
    Forum|alt.badge.img+1
    • jfavContributor
    • Author
    • Contributor
    • March 11, 2026

    Hi,

    Thank you for your answer.

    I tried running the workspace with a more recent version (2025.2.4), but unfortunately the issue still occurs.

    To better explain my use case, the writer receives features coming from different layers where the attribute structure is not the same.

    For example:

    Feature 1

    fme_feature_type = enu_cad_caracteristique_constructive attributes: ID valeur

    Feature 2

    fme_feature_type = ma_maj
    attributes:
    pk_id_maj
    remarque
    commune

    ...

    The destination database already contains the tables with the same structure:

    enu_cad_caracteristique_constructive(ID, valeur)ma_maj (pk_id_maj, remarque, commune,...)

    With the FeatureWriter configured as follows:

    • Table Name = fme_feature_type

    • Attribute Definition = Automatic

    The expected behaviour is that the writer takes each incoming feature, detects its attributes, and writes it to the corresponding table while respecting the existing schema in the destination database.

    It seems that because AttributeManager_3 modifies (and therefore exposes) some attributes (such as pk_id_maj, remarque, commune, etc.), the writer tries to include these attributes for every feature. As a result, the writer attempts to insert them into all tables with a NULL value, even though these attributes only exist in a specific table.

    This workflow worked correctly in FME 2023.2, but in FME 2025 it seems that the writer no longer detects the attributes when the table name is dynamic, resulting in the error "No valid columns provided".

    Does this behaviour sound familiar, or could it be related to another change in dynamic writing?

    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.