Skip to main content
Solved

"Error running translation" when writting data to ESRI ArcSDE table

ostoja
Contributor
Forum|alt.badge.img+2

I have a very basic workbench, which reads data from FFS files and should write around 15000 lines in the ESRI ArcSDE Table (SQL Server 2014). Unfortunately, when the workbench is ready to write the data in the table, I receive "Error running translation" with two BADNEWS issues in log which appear only in Debug mode:

....

ArcSDE release: '10.0'. Underlying database: 'SQL Server'

A default z-value of '0' will be used for all 3D features where z-values are not provided

Geodatabase Writer: Not simplifying geometries being written to the Geodatabase

Error running translation.

.....

Kindly find complete log here

 

The writer which I use is "Esri Geodatabase (ArcSDE Geodb)". The same behavior I have with writer "Esri Geodatabase (Personal Geodb)" but if I change the writer to pure Microsoft Access, I am able to write in the data.

 

In the Win Event Viewer I can find two error messages each time I execute the test (sorry that it is in German)

I am using FME Desktop 2018.1.0.2 Build 18547 (32 bit).

On the same machine is installed ArcGIS 10.2.1 with Utility and Telecom Patch 8, HotFix 364568 and VBA Compatibility 10.2.

Thanks in advance for any comment or advice what can I implement in order to properly write the data in the SDE.

Dušan

Best answer by chrisatsafe

Hi @ostoja,

If you haven't already done so, can you please submit a case for this issue along with the workspace/ffs file?

Is this the first time running your workspace or did this translation work in a previous build of FME? One potential workaround could be to try and run the translation in a previous version, such as 2018.0.

View original
1 Attachments
Did this help you find an answer to your question?

10 replies

chrisatsafe
Contributor
Forum|alt.badge.img+2
  • chrisatsafeContributor
  • Contributor
  • Best Answer
  • December 7, 2018

Hi @ostoja,

If you haven't already done so, can you please submit a case for this issue along with the workspace/ffs file?

Is this the first time running your workspace or did this translation work in a previous build of FME? One potential workaround could be to try and run the translation in a previous version, such as 2018.0.

ostoja
Contributor
Forum|alt.badge.img+2
  • ostojaContributor
  • Author
  • Contributor
  • December 12, 2018

Hi @ChrisAtSafe,

Thanks for the hint! After installing 2018.0.1.0 I managed to write the data in the table.

Best regards and thanks once more,

Dušan

chrisatsafe
Contributor
Forum|alt.badge.img+2
  • chrisatsafeContributor
  • Contributor
  • January 22, 2019
chrisatsafe wrote:

Hi @ostoja,

If you haven't already done so, can you please submit a case for this issue along with the workspace/ffs file?

Is this the first time running your workspace or did this translation work in a previous build of FME? One potential workaround could be to try and run the translation in a previous version, such as 2018.0.

It looks like another workaround for this is to expose and remove the fme_template_feature_type format attribute. Our team is looking into this issue and we will update this post when it is resolved.

ostoja
Contributor
Forum|alt.badge.img+2
  • ostojaContributor
  • Author
  • Contributor
  • May 28, 2019

Hi @chrisatsafe,

Here is a small update on this topic.

I noted similar issue in FME 2019.0.1.0 (Build 19253 - WIN64). This time I am working with Oracle 12c as RDBMS and all other parameters, including the writer, are the same. Issue is very similar - I am able to write FCLs but as soon as I try to write in GDB Table, "Error running translation" pops up with no other message.

Following message was present in the Event Viewer

Faulting application name: fme.exe, version: 2019.7.36.19253, time stamp: 0x5cd0fa1f

 

Faulting module name: KERNELBASE.dll, version: 10.0.17134.753, time stamp: 0xcdfe5b92

 

Exception code: 0xc0000005

 

Fault offset: 0x000000000003a388

 

Faulting process ID: 0x4ae8

 

Faulting application start time: 0x01d515563cd4f24d

 

Faulting application path: C:\\Program Files\\FME\\fme.exe

 

Faulting module path: C:\\Windows\\System32\\KERNELBASE.dll

 

Report ID: 36d417dd-3e7b-439f-b515-9657bd0ef813

 

Faulting package full name:

 

Faulting package-relative application ID:

 

After applying your trick with the fme_template_feature_type attribute, I am able to write the data in the GDB Tables. I noted that the writer performance is very poor in this case and significantly different from the writing to FCLs.

Hope you will be able to fix this issue soon.

martinkoch
Supporter
Forum|alt.badge.img+18
  • martinkochSupporter
  • Supporter
  • June 5, 2020
chrisatsafe wrote:

It looks like another workaround for this is to expose and remove the fme_template_feature_type format attribute. Our team is looking into this issue and we will update this post when it is resolved.

Thanks... another day saved....

Two days ago all went fine writing features with some workspace. Today I changed almost everything before the FeatureWriter, and boom!!!

Some hours and a lot more tries later I found this, and it appears under the current moon-phase I seem to need to remove the fme_template_feature_type.

dustin
Influencer
Forum|alt.badge.img+30
  • dustinInfluencer
  • Influencer
  • October 22, 2020
chrisatsafe wrote:

It looks like another workaround for this is to expose and remove the fme_template_feature_type format attribute. Our team is looking into this issue and we will update this post when it is resolved.

I know this is an old thread, but I'm getting the same from FME2019 build 19617. Exposing and then removing fme_template_feature_type still rectifies the issue.

messagemauri
Contributor
Forum|alt.badge.img+6
  • messagemauriContributor
  • Contributor
  • January 22, 2021
chrisatsafe wrote:

It looks like another workaround for this is to expose and remove the fme_template_feature_type format attribute. Our team is looking into this issue and we will update this post when it is resolved.

Thanks for this post. I'm having this issue on FME Server 2019. It works fine on FME Desktop.

 

Where do you expose and remove the fme_template_feature_type? Is this on the FeatureReader? I don't see it. I only see FME_Feature_Type. Thank you.

 

fme_feature_type 

dustin
Influencer
Forum|alt.badge.img+30
  • dustinInfluencer
  • Influencer
  • January 22, 2021
chrisatsafe wrote:

It looks like another workaround for this is to expose and remove the fme_template_feature_type format attribute. Our team is looking into this issue and we will update this post when it is resolved.

You will need to manually expose in an AttributeExposer.

messagemauri
Contributor
Forum|alt.badge.img+6
  • messagemauriContributor
  • Contributor
  • January 22, 2021
chrisatsafe wrote:

It looks like another workaround for this is to expose and remove the fme_template_feature_type format attribute. Our team is looking into this issue and we will update this post when it is resolved.

Thanks for the feedback @dustin​ .

 

Sorry but is this correct (see below screen capture)? I placed it behind the writer. I expose it but I thought we needed to expose and remove? Do I need to place an AttributeRemover right after the Attribute Expose? Thank you.

attribute_exposer 

dustin
Influencer
Forum|alt.badge.img+30
  • dustinInfluencer
  • Influencer
  • January 22, 2021
chrisatsafe wrote:

It looks like another workaround for this is to expose and remove the fme_template_feature_type format attribute. Our team is looking into this issue and we will update this post when it is resolved.

This is correct, and yes, AttributeRemover right after.

Reply


Helpful Members This Week

Community Stats

31,250
Posts
118,502
Replies
38,840
Members

Latest FME

Terms & ConditionsCookie settings

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
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.