Ignoring order of actions within an "If-then-else"

Has anyone else noticed an issue with the order of actions being ignored within an if-then-else in automation designer? I’m using Toad 11.6.

If I have several actions within a “then” (e.g. export generically-named table, then rename table, etc.), the process often fails because it appears that Toad will rename the table before it gets to the export step – and then the export step can’t find the table to export.

I can easily work around it by changing my “if” condition, but I’m just wondering if anyone else has noticed this. Outside of if-then-else, the order of actions seems to work fine.

I was keeping an eye on this to see if anyone took it but they haven't yet..

There's definitely funk going on here. I did this:




Export Dataset


It blows right past the export dataset, not even running it, and shows Message2. Running just the export dataset by itself works fine.

I replaced the Export Dataset with a Script Execution, and the Script Execution action runs as designed, even with threading on it waits until finished then
shows message 2.

Actions and Apps are designed to run synchronously, so that control structures and fail conditions can be respected. This wasn't always the case; earlier Toad
versions saw some asynchronous behavior creep in. This appears to be one of those cases.

I checked and the behavior works correctly in Toad 12 (though I did notice that Exporting the If/Then Action and Importing it into T12 has a bug in that it
lost the structure order).

Are you able to upgrade?

My team is still noticing this issue and we are using TOAD 16.1. Any ideas @JohnDorlon?

Here is some more detail to recreate this problem:

  1. create a new automation
  2. add several steps, can be a mix of exports, imports, and execute scripts
  3. rename the steps 01_STEP, 02_STEP, ... N_STEP so you can see the original order
  4. export the automation
  5. close automation designer window
  6. open the automation and confirm the steps are in the correct order
  7. Add an IF_THEN_ELSE
  8. Create an execute step under IF
  9. Create an execute step under ELSE
  10. Highlight the N steps created in steps 2 and 3 and move them under then THEN
  11. Close the automation designer
  12. Reopen the designer and note that the steps are now out of order.

With this simple example, one can fix the problem by simply rearranging the steps back into the correct order, closing the automation window, and reopen to confirm they are still correct.

However, with larger or more complex automations, It can take many attempts to the get the steps back into the correct order and have them "stick" where they belong.

Offhand, I have no idea on this.

I've logged it so I don't forget about it.

Ah-hah! Now I can reproduce it.

Shortened steps are:

  1. Drop 4 actions into an empty App in AD. (I did 4 message actions)
  2. Drop an if..then into the app after the message actions
  3. Drag the message actions into the "Then" part
  4. It looks right. Order of the message actions has not changed.
  5. Close and open AD.
  6. Bug: Actions in the "Then" part are now in reverse order.

The bug happens in any of the sections (if, then, or else), so here is a workaround:

  1. Drag items to a section where you don't want them. So, if you want them to end up in THEN, drag them to either IF or ELSE.
  2. Close and re-open AD. They are in reverse order.
  3. Drag them to THEN.
  4. Close and re-open AD. Now the order is correct and they are where you want them.

I also found this bug:

  1. Select multiple actions
  2. Drop them onto one of the selected actions
  3. Bug: Order changes

We should not allow drop in that case. I could see this happening if you started to drag some nodes, then maybe you change your mind and then drop them in the same place that you started (to not drop them anywhere).