Skip to main content
Solved

Error writing dynamic features in FME 2015.1


Since upgrading to FME Desktop 2015.1 and Server 2015.1 we've hit an error writing dynamic features to a file geodatabase:

 

 

Unable to find the schema definition 'Scheduled_Ancient_Monuments' for feature with feature type name 'Scheduled_Ancient_Monuments'. Ensure the feature type name is correct and that its schema definition exists in the schema source

 

 

We haven't changed anything between 2015.0 and 2015.1 and it worked fine previously. I've attached two images showing the Feature Type Properties as they look in 2015.0 and how they look in 2015.1.

 

 

Thanks,

 

 

Peter.

 

 

 

 

Best answer by takashi

This is my guess.

 

 

FME 2015.0 and earlier

 

According to the Workbench help doc, the "From Attribute" value should be used as the identifier of schema definition, if you choose "From Attribute" for "Feature Type Name" and also choose "Default" for "Schema Definition".

 

However, as far as I know, it didn't work in fact. "fme_feature_type" has been always used as the identifier when you have chosen "Default" for "Schema Definition". It did not matched to the help doc, but has been a kind of "de facto" specification.

 

 

FME 2015.1, 2015.1.0.1

 

Tthe mismatch situation has been resolved. If you leave the "Schema Definition Name" Default, value from the feature type name field (Feature Class or Table Name) will be used as the identifier of schema definition.

 

That's an improvement, but it caused a side-effect to some workspaces created in the previous version having settings related to the "de facto" specification. That's the situation you have encountered, I think.

 

 

FME 2015.1.0.2

 

Dynamic writer feature type seems to set "fme_feature_type" automatically to the "Schema Definition Name" for the workspace that was created with previous version, if the original "Schema Definition" parameter setting was "Default". Maybe this is the solution to avoid the unpreferable result brought by the side-effect.

 

 

Hope someone from Safe will leave a comment about this.
View original
Did this help you find an answer to your question?
This post is closed to further activity.
It may be a question with a best answer, an implemented idea, or just a post needing no comment.
If you have a follow-up or related question, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.

7 replies

takashi
Influencer
  • May 29, 2015
Hi Peter,

 

 

In fact, there were some inconsistency on the Dynamic Properties between FME 2015.0 and FME 2015.1 / 2015.1.0.1. Probably the issue has been resolved in the latest version - FME 2015.1.0.2 build 15482.

 

 

Takashi

Hi Takashi,

 

 

Thanks for your reply, I've updated FME Desktop but I am still getting the error. If I clear the Schema Definition name field so it is using the default for the Feature Class then you get the error. If I put in fme_feature_type it works okay but I think this is then using the schema from the reader when I want it to use the schema from the dynamic dataset I am writing to.

 

 

Thanks again,

 

 

Peter.

Sorry, I didn't phrase that very well. I've done some more testing and can see what the behaviour is in the new release. Now, I'm not sure why it hasn't errored before!

 

 

My reader is called: SCHEDULED_ANCIENT_MONUMENT and my destination feature class is called Scheduled_Ancient_Monuments (note the 's' at the end). In the dynamic writer I have the Feature Type Name set to Scheduled_Ancient_Monuments from an attribute defined in the workbench and I have the Schema Definition set to Default.

 

 

I can see now why in the new version it reports an error because Scheduled_Ancient_Monuments doesn't exist as a reader feature type name. How was it working correctly in previous versions of FME though? I've checked the logfile and can't see any indication why it was working okay.

takashi
Influencer
  • Best Answer
  • May 29, 2015
This is my guess.

 

 

FME 2015.0 and earlier

 

According to the Workbench help doc, the "From Attribute" value should be used as the identifier of schema definition, if you choose "From Attribute" for "Feature Type Name" and also choose "Default" for "Schema Definition".

 

However, as far as I know, it didn't work in fact. "fme_feature_type" has been always used as the identifier when you have chosen "Default" for "Schema Definition". It did not matched to the help doc, but has been a kind of "de facto" specification.

 

 

FME 2015.1, 2015.1.0.1

 

Tthe mismatch situation has been resolved. If you leave the "Schema Definition Name" Default, value from the feature type name field (Feature Class or Table Name) will be used as the identifier of schema definition.

 

That's an improvement, but it caused a side-effect to some workspaces created in the previous version having settings related to the "de facto" specification. That's the situation you have encountered, I think.

 

 

FME 2015.1.0.2

 

Dynamic writer feature type seems to set "fme_feature_type" automatically to the "Schema Definition Name" for the workspace that was created with previous version, if the original "Schema Definition" parameter setting was "Default". Maybe this is the solution to avoid the unpreferable result brought by the side-effect.

 

 

Hope someone from Safe will leave a comment about this.

Thanks Takashi, that makes sense now and I've altered my workbenches accordingly. All seems to be running correctly again now.

  • June 2, 2015
Hi Peter,

 

 

Thank you very much for posting about this issue. Takashi is correct in his timeline above and explained the issue very well.  We have created an article to help others who have encountered the same thing at the following link:

 

 

https://knowledge.safe.com/articles/Error_Unexpected_Behavior/Dynamic-Workspace-using-FME-2015-1-Cannot-Find-the-Schema-Definition

 

 

Regards,

 

 

Brian

Hi Brian,

 

 

Thank you for your reply and the URL, it is very useful. I've figured out what I need to do now to my workbenches.

 

 

Regards,

 

 

Peter.

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings