Dynamic Writer adds geometry type to the name

Writer set up like this:

Setting the geometry type from the first feature does not solve it since it can be wrong!

Can you introduce a test so that the first feature will never be wrong?

The error I get: 2020-05-19 16:35:04| 35.7| 15.0|ERROR |Geodatabase Writer: Feature Class or Table 'FILENAME_polygon' must exist when Table Handling is set to 'Truncate Existing'

It still adds the prefix to the name,...

I don't quite understand how this happens to be honest. If I write to a shapefile dynamically with geometry set to From Schema Definition any feature not meeting the right geometry type is rejected and not written...

What version of FME are you using?

I'm using FME(R) 2019.2.3.1 (20200212 - Build 19823 - WIN32)

And I'm reading an Oracle SDE geodatabase and one table can contain many geometry types. I'm writing to an SQL Server database (with a Esri Geodatabase Writer)

I guess I can write to a temporary table and then use SQL executor to copy from it to the final table, but this will make the whole process with hundreds of tables slower.

Do you read from a generic / multigeometry type table?

Yes, from an Oracle SDE / ESRI Geodatabase.

ESRI's featureclasses are single geometry type. Points or Polylines or Polygons etc. If the input table "A" is multi geometry (points and polygons for example) the proces wil fail, because it tries to create a table "A" with type points and when a polygon arrives it will overwrite the featureclass with type polygons.

I can reproduce this.

I think your source table is generic type geometry (can contain points / lines / polygons etc) and it probably contains different geometry types.

I could reproduce this when reading from postgis generic geometry tables and write to gdb, but only when the source table contained multiple geometry types.

When the generic geometry type source contains only one geometry type features (for example points) and the dynamic writer is set to "First Feature Defines Geometry Type" it works as expected.

Okay thanks for looking in to it. So it doesn't add the geometry type to the name then!? Unfortunately this doesn't still solve my problem.

If you have a multi geometry featureclass named "trees" containing points and lines, and you want to write it to a point featureclass "trees", then what has to be done with the lines?

You wrote you want to truncate and write to existing featureclasses, so you already know what the target geometry type should be, right?

You can choose for different strategies here:

1. Validate the source data using the target data featureclass / geometrytype combination.
   1. It's probably easy to analyse the size of the mismatches.
   2. This might be expensive to repair, depending on the number of featureclasses and features.
   3. You are in control of what you are doing.
2. Write the source data to the targetdata where it fits (only the points from trees) and ignore the failed features.
   1. This is cheap.
   2. You might be losing a lot of data.

Personally I always want to know what is happening, so I would at least check what I'm going to loose. But its probably correct to loose the lines from trees, as it was incorrect data to begin with. Hard to say without context.

Adding the answer here in case it is useful for someone else. When using a schema feature with a dynamic writer for formats that require separate feature types for each unique geometry like Geodatabase, a second list attribute named fme_geometry is required. The value should be fme_type attribute value for the geometry.

Once this list attribute has been added, then the feature name will not have the geometry type appended.