Skip to main content

Hi everyone,


I'm working on a workflow that writes/updates features to an ArcSDE database using FME. The process completes successfully without any errors or crashes. However, I've noticed that for certain tables, the geometry (and possibly other data) is not actually updated in the ArcSDE database.

I'm fairly new to ArcSDE and would appreciate any guidance on what might be causing this issue. Specifically, I’d like to understand:

  • What table properties or configurations could prevent updates from being written, despite a successful translation?

  • Are there permissions, versioning, or schema-locking issues I should be aware of? This is a non versioned table but the writer only works if I select versioned. Archiving is activated for the specific table.

  • Is there a difference in how certain tables are registered with the geodatabase that could affect write operations?

Any tips on how to investigate this further or best practices when working with ArcSDE and FME would be greatly appreciated!

Thanks in advance

  • What table properties or configurations could prevent updates from being written, despite a successful translation?

When features with a different geometrytypes then the corresponding featureclass arrive at a SDE (Feature)Writer, they will not be written. You will see warnings in the log, but the translation will be succesful.

This is a know point of improvement, an Idea for a Rejected outputport for the FeatureWriter exists, but is not implemented so far.

 


Another thing to also be aware of is slither polygons (and very short lines) that may be collapsed to a line/point depending on the precision set in the destination.

FME will treat them as very small polygons/lines but when theyre passed to the writer, the destination applies the precision it has set and round the coordinates to match. This may result in the geometry ‘collapsing’ to a line (in the case of a polygon) or a point (both line and polygon)


Reply