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.
This post is closed to further activity.
It may be a question with a best answer, an implemented idea, or just a post needing no comment.
If you have a follow-up or related question, 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 a question with a best answer, an implemented idea, or just a post needing no comment.
If you have a follow-up or related question, 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.
Helpful Members This Week
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.