Skip to main content
  • EN
  • Home
  • Forums
  • FME Form
  • Data
  • Esri Geodatabase (ArcSDE Geodb) writer is not updating features despite log indicating successful translation

My workspace compares data from an Oracle database and a versioned SQL Server backed Esri Geodatabase. The Oracle database contains mostly CAD and MapInfo data. It's the source of truth for the data. The SQL Server database is the destination where changes to the source should get written.

 

I am using a change detector to determine if there are any differences between the features. The process generally works ok. The change detector populates the fme_db_operation attribute appropriately, and I'm using that to set the Feature Operation.

 

My problem is that the process doesn't seem to update the features. The log indicates that it wrote the features and that the translation was successful. However, when I try to view the data in ArcGIS Pro, I'm not seeing the changes.

 

If the process was successful, if I ran it again, I should see zero features that need to be updated. However, I get the same number of features that need to be updated over and over again.

 

What could be causing this failure to write the features?

 

I should add, that since the data in the Oracle database is CAD, there are some strange features which can be quite complex multipart features often with holes (donuts). Whilst not typical of GIS data, I wouldn't think this would be a problem.

 

My feature writer is set to use Transaction Type: Versioned Edit Session. I have deleted unused versions, and compressed the database. Here are the other settings in my writer.2021-01-08_17h15_42Any ideas why I can't update these features?

 

@rchoucroun​  We recently presented a couple of webinars on Change Detection, Part 1 & Part 2. The first one might give you some ideas on what's going wrong here. Some possible ideas:

  • Is the ChangeDetector correctly flagging the changed features? Check the output of the Change detector to check the features have the expected fme_db_operation value
  • if you have complex geometry, they might not match the way esri stores geometry. Sometimes you have to round the coordinate (CoordinateRounder) but there might be other changes, like reversing the direction of donut holes.
  • what's in your 'where_clause' attribute? is that join being done correctly?

If these thoughts don't help, you might need to contact your FME reseller for support so they can look at the problem and your data more closely.

@rchoucroun​  We recently presented a couple of webinars on Change Detection, Part 1 & Part 2. The first one might give you some ideas on what's going wrong here. Some possible ideas:

  • Is the ChangeDetector correctly flagging the changed features? Check the output of the Change detector to check the features have the expected fme_db_operation value
  • if you have complex geometry, they might not match the way esri stores geometry. Sometimes you have to round the coordinate (CoordinateRounder) but there might be other changes, like reversing the direction of donut holes.
  • what's in your 'where_clause' attribute? is that join being done correctly?

If these thoughts don't help, you might need to contact your FME reseller for support so they can look at the problem and your data more closely.

Thanks @Mark Stoakes​ 

yes, I have watched both of those webinars and in fact have rounded coordinates to 4 decimals, oriented all polygons using the right hand rule (even tried left hand rule). The where clause is just ASSETID='12345'.

 

when you say “they may not match the way esri stores geometry” do you have a link describing how esri stores geometry? I do have a geometry validator in place and it is not finding anything wrong with the geometry.

 

I should add that we found two of the features had self intersections. These did not get picked up by the geometry validator. But we fixed them up and they wrote correctly. But I don’t know how to fix hundreds or thousands of features if the geometry validator lets them pass.

Thanks @Mark Stoakes​ 

yes, I have watched both of those webinars and in fact have rounded coordinates to 4 decimals, oriented all polygons using the right hand rule (even tried left hand rule). The where clause is just ASSETID='12345'.

 

when you say “they may not match the way esri stores geometry” do you have a link describing how esri stores geometry? I do have a geometry validator in place and it is not finding anything wrong with the geometry.

 

I should add that we found two of the features had self intersections. These did not get picked up by the geometry validator. But we fixed them up and they wrote correctly. But I don’t know how to fix hundreds or thousands of features if the geometry validator lets them pass.

@rchoucroun​  You probably need to contact your FME provider for support. They would be able to look at your data and see if they can isolate the cause of the problem.

Thanks @Mark Stoakes​ 

yes, I have watched both of those webinars and in fact have rounded coordinates to 4 decimals, oriented all polygons using the right hand rule (even tried left hand rule). The where clause is just ASSETID='12345'.

 

when you say “they may not match the way esri stores geometry” do you have a link describing how esri stores geometry? I do have a geometry validator in place and it is not finding anything wrong with the geometry.

 

I should add that we found two of the features had self intersections. These did not get picked up by the geometry validator. But we fixed them up and they wrote correctly. But I don’t know how to fix hundreds or thousands of features if the geometry validator lets them pass.

Upon further investigation, I have discovered that many of the shapes have vertices closer than the resolution of the feature class. When the data is being written, it is removing or moving some of the vertices. Therefore, when the process runs again, the change detector is seeing these as different geometries. I have attempted to round coordinates to match the resolution of the feature class which works for some cases, but not all. I'm going to attempt to generalise the geometry and see if that makes a difference.

 

Reply


Community Stats

29,747
Posts
113,047
Replies
37,398
Members
Terms & ConditionsCookie settings