[BUG] Automation Log File Behavior

Toad Data Point & Toad Intelligence Central
1

I found what I think is a bug with the log file behavior with TDA. I’m posting this here instead of in the beta forum because it affects the current release of TDA for sure.

The bug is subtle, but it caused us a huge problem today.

By default, TDA wants to store the log files in C:\Documents and Settings<user>\Application Data\Quest Software\Toad for Data Analysts \Automation for any automation jobs that you build.

However, TDA gives you the option to change the path, and with all of my jobs I do - I point it at a network share folder so that they are accessible to anyone for troubleshooting, not just those of us that know the U/P to the automation machine.

However, it seems that TDA does not always want to accept this path, despite giving no indications otherwise. The first clue that something wasn’t right was when I edited the “error email” and looked at the attachments and saw that the log file it was attaching was still pointing at the local C drive, instead of the network share. Deleting the attachment, closing, going back and it still wanted to only use the one on the C drive, despite having changed the path location.

Now, for the reason why this bugged out today - I had moved a .Job file from one machine to another. All the paths were fully qualified network names, including those in the .TAS file, so there was no need to edit the .TAS file - or so I thought.

When the job tried to run today, it errored out - because the path to the log file (on the local C drive) wasn’t valid (the “Automation” folder and indicated “MailBee” file didn’t exist), despite the .TAS file having the path set to the network share.

The only way I was able to work around this was to edit the automation error email settings, un-check the “Attach log file to email” check box, delete the entire contents of the “Logging folder path” box, Click the “Compose Email” button and delete all the attachments. Then I had to re-enter the path in the “Logging folder path” box, re-check the “Attach log file to email” check box, then edit the error email to attach the log file - at which point the path displayed when hovering over the attachment showed the correct network path.

This was a lot of steps to go through to fix this issue. Is there any chance that TDA can be updated to always and ONLY use the path in the “Logging folder path” box?

2

Appears I spoke too soon - the automation script is still looking for the file in the local directory that doesn’t exist, and still erroring out when it tries to send an email.

I really don’t want to have to re-write these .TAS files from scratch; some of them are incredibly complex.

3

I tried this in our 3.2 code and this works without manually updating. Can you down load and try our Beta?

What I did is create a script that used default logging and attached the log file when there was an error. Then I changed the path of the log file to a different path. The error email got the new log file.

Debbie

4

Hi Debbie,

After some tinkering, I think I found the root of the issue.

Namely, the “Automation” sub-folder was not created at install of TDA on that machine, nor was it created by any subsequent actions involving automation scripts on that machine. Once I created the folder, the script ran without issue. What I don’t understand is why the folder wasn’t created automatically or by any subsequent actions.

The folder only seems to either serve as A) the default folder for logging, or B) a temporary folder for the log file - which I don’t understand, as the log file should be stored in the folder indicated by the path and not anywhere else.

Regarding the attachment - I’m still observing the behavior where it fails to attach the log file from the path that I set.

I may try 3.2 and see if the behavior disappears, but I’m under a very tight deadline to get these reports moved during the maintenance window tonight.

Debbie Peabody wrote:

I tried this in our 3.2 code and this works without manually updating. Can you down load and try our Beta?

What I did is create a script that used default logging and attached the log file when there was an error. Then I changed the path of the log file to a different path. The error email got the new log file.

Debbie