Skip to main content

I am reading data from SQL Server that is in the default dbo schema. I want to write the data into a specific schema in postGIS.

But i struggle to make to do this as a dynamic workbench.
The setting is to Always create tables. The table is created as expected (dbo. is replaced with correct postgis schema name in StringReplacer).
But i get an error trying to write feature

POSTGIS Writer: Fanout for feature type '' failed to find feature type template ''

Seem to be a missmatch between the schema feature and the feature itself?

 

 

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.

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.
 

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.

Community Stats

32,023
Posts
121,624
Replies
39,646
Members

Latest FME

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.