If the fault happens after the first transaction has been committed to the database, the updated data from the writer will indeed persist after FME has failed.

Thank you for your answer David,

We did a test to find out more. First we had the feature class of the first writer locked. This would raise an error at the beginning out the write proces. No data changes were made.

After that we locked a feature class of the second writer which had several feature classes. If we would have the transaction type parameter on Transaction (the default) this would lead to corrupt data. If we would have the transaction type on Edit session no data changes were made.

So I seems as if this would lead to a good error handling mechanism.

• Do you know if this would be a correct solution?
• Any idear if this leads to a heavy database load?

   

  I guess the database will have to monitor the rollback needed after an error

Greetings from the Netherlands

I've not used Edit Sessions much at all, partly because they can be painfully slow to work with, and partly because they are proprietary and opaque. Personally I try to stay away from vendor-specific solutions when there are well-established and widely accepted ways of achieving the same thing, e.g. using database transactions and staging schemas.

Of course this doesn't mean that Edit Sessions couldn't be the right choice for your situation, but simply that I'm probably not the right person to answer the question for you, especially with such limited knowledge about your specific case.

If this is a business critical issue for you, my recommendation would be to reach out to your local FME and/or ESRI partner for further discussions.

Thank you for your Answer David,

We will keep that in mind in our project.