How to control schema/table qualifier in a dynamic workbench

What version do you use exacty? Have you tried to use a FeatureWriter instead of a classic writer?

I’m asking this because there were issues with an earlier version of 2025. As far as I know 2025.1.0 had an issue with dynamic writing, 2025.1.1 solved the issue for FeatureWriters, 2025.1.2 solved it for classic writers. But I never use the classic writers so I have not tested that myself.

I just downloaded the latest version 2025.1.1 and i am using the FeatureWrtier. 
So i dont think it it part of the issue. I think the main issue is with my schema handling. 
I can for example see that the data features fme_feature_type value still has dbo.<nameOfFeature>, whereas in my stringReplacer for the schema feature has removed the dbo. prefix.
It is getting complicated and confusing to match them up, assuming both fme_feature_type and the schema feature need to have the same name. I am not sure how it really works, but it start to feel hacky.

Further more i also see now that my SQL Server is using native geometry and not OGC geometry so FME is not recognizing the geometry. The only way i can get the geometry so far is by using SQLExedcutor forcing it to Well Known Binary with  ,[Geometri_SPA].STAsBinary ( )  as geom
Then using GeometryReplacer changing the geometry encoding to something FME understands.

 

The last version is 2025.1.3.1.

I will admit that this stuff also feels hacky for me. I think that the fme_feature_type and the fme_feature_type_name should be the same, but I have not seen anything about it in the documentation. In your case, I would submit a case at Safe to get some guidance. This probably will help you more than asking on the forums as what you try to do is not so common.

I’m not even sure if I have a PostGIS db installed to test right now.

How are you connecting to your SQL Server? If you use an ODBC connection, then yes, geometry won’t come through properly (because ODBC does not support it), and you’ll have to use WKT or WKB. But if you can use a regular SQL Server connection, FME does not have a problem with geometry at all. I use it all the time that way.

I have used both SQL Executor and the ODBC connection. But i am an “edge case” in with that as well because my tables have at least 2 geometry columns, reason -the “industry” standard i am working with. FME will use the first column it finds having geometry data, and in some cases it does not hold the geometry type i am looking for. That’s the reason i am using SQL Executor so i can have full control of what i bring into the workbench.

Those are two different things… the first is a Transformer, the second is a data format.

An ODBC database connection does NOT support geometry, whether it is one or more columns. In your SQL Executor (which is a Transformer), you should select Microsoft SQL Server (MSSQL) in the Format: dropdown. Then add the desired geometry column to your sql statement, and FME should recognize it as the geometry. 

As said, I have at least 2 dozen tables with multiple geometry columns, and this way works just fine for me, whether using Readers, FeatureReaders, SQL Creators or SQL Executors. But selecting ODBC 3.x  as a Format will not work, because ODBC does not handle geometry.