Let's say that before an Oracle writer, I have a Counter and Stats Calculator. I use the total count of features as a condition in my Oracle writer to commit or rollback my transaction. If the right number of features were inserted, commit. Else rollback. Recplicating this with SQLExecutors is possible but involves a lot of hardcoding.
Archived
Oracle writer - Commit/Rollback based on conditions
This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
There are already some ideas floating about how to improve / extend on the transaction support in FME based on use-cases very similar to yours, but I'm not sure if there's a very simple solution. The problem is that you really want to limit the possibility of ending up with a humongous transaction that takes forever to commit/rollback or fills up the database logs.
If you have a suggestion for how to implement it, I'm sure Safe would be interested to hear about it.
One common "best-practice" way of working around this is to use a staging schema, which is basically an empty copy of the production schema: load the data into the staging schema, validate and transfer to the production schema only if the validation was ok, otherwise emtpy the staging schema.