Skip to main content
Question

Issue with Rollback functionality for ESRI Geodatabase

  • September 13, 2018
  • 2 replies
  • 29 views
J

Hi All, I am using ESRI Geo-database (10.4) Writer that updates a feature class in a geo-database (hosted on SQL Server). I have business requirement where if there is an error during writing there are no records committed. I found a property on writer: “Commit Transactions at the the end of the write” and set it to yes. During one of the runs, there was an error while writing, I was expecting that original state of feature class would be maintained but that didn’t happen. I am not sure what I am missing here. Are there any change required on geodatabase side for this. Appreciate any feedback.

Thanks

Jay

 

2 replies

M
Forum|alt.badge.img+2
  • markatsafe
  • September 14, 2018

@jayd3vl This is poorly explained in the documentation (under the section ArcSDE Geodb Writer Parameters). This parameter fine tunes the timing of the commit, either immediately after the last transaction, or just at the start of the next transaction. I have to admit I don't understand the subtle difference there.

To do what you want to do - roll back if there is any failure then you need to set the Feature per Transaction to a very high value - greater than the number of records you expect to write. Then the commit will only occur at the end of the data load. This can have consequences for your database tmp file sizes that might need DBA assistance (I know that can be an issue on Oracle, I'm not sure about SQL Server).

Another approach is to use staging tables to ensure that everything worked and then move the data to production. We talk a little bit about these issues in this webinar.

J
  • jayd3vl
  • Author
  • September 14, 2018
markatsafe wrote:

@jayd3vl This is poorly explained in the documentation (under the section ArcSDE Geodb Writer Parameters). This parameter fine tunes the timing of the commit, either immediately after the last transaction, or just at the start of the next transaction. I have to admit I don't understand the subtle difference there.

To do what you want to do - roll back if there is any failure then you need to set the Feature per Transaction to a very high value - greater than the number of records you expect to write. Then the commit will only occur at the end of the data load. This can have consequences for your database tmp file sizes that might need DBA assistance (I know that can be an issue on Oracle, I'm not sure about SQL Server).

Another approach is to use staging tables to ensure that everything worked and then move the data to production. We talk a little bit about these issues in this webinar.

 

Thanks Mark for your feedback. In this case, i have a small feature class with just 200 records, I did push the Feature to write Per Transaction to a very high number but I am not getting the expected result. Here are the settings that I am using for the writer, not sure if I further need to tweak it. Thanks Jay

 

 

Reply


Helpful Members This Week

Community Stats

31,350
Posts
118,920
Replies
38,965
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.