We have automated reports that connect to a third party resource for source files. That password needs to be updated every two months. We reset the password last Friday and updated TOAD with the right password, successful test, saved, and closed TOAD.
Scheduled reports ran Sunday unsuccessfully, and I found the account locked out Monday.
We reset the password Monday, updated TOAD with the right password, successful test, saved, and closed TOAD. Kicked off the reports that didn’t run Sunday and they completed with no issues. Scheduled reports ran unsuccessfully this morning (Thursday) and the account is again locked out.
After some investigation, I have found password references in the TAS files that are static, and password references in the ftpconnections.xml file that update as we change password in TOAD.
Two things come to mind... either TOAD is using a cached password that I don't know about, or it is relying on a password stored in each TAS (this approach would be ridiculous). So the password reference in each TAS must refer to a connection in the ftpconnections.xml file. Since that must be the case, each TAS would have the new password on hand at any given run time (unless it is cached somehow). I can't find any settings in TOAD Data Point options.
Why would this suddenly start happening after we updated password when previous to last Friday these were running flawlessly? I might think it is new settings at the remote system but that would be quite coincidental.
These surround compliance reporting so we cannot miss a step, and this issue makes automating the process moot.
Any thoughts?
TDP 5.3.33
Win 10 Ent 1909
My first thought--assuming you haven't changed anything in the TAS script file, or admin changes haven't happened at the FTP server site regarding permissions, or you haven't changed versions of TDP, etc. etc.-- matches yours regarding some kind of caching with the password, although I'm not sure why TDP's behavior would suddenly change.
My second thought is that there has been a change in the user permissions on the FTP site. In your FTP task within your script, what's the retry count and wait interval set to? It may be that the retry count exceeds the allowable (which would lock out the account) or the wait interval might be too fast all of a sudden?
1 Like
Thank you, Gary. We don't set the retry count; it is still the default zero. Additionally, we have not incorporated a retry/reconnect algorithm.
TOAD Data Point (TDP) has an idiosyncrasy with multiple TDP instances where settings/options changed don't get saved. I thought that might be it... we'll have orphaned scheduled TDP instances running in the background at times... might be it too. I ruled that out by having only one instance running and any background orphans were closed.
So TDP caches TAS, and SQL files (not sure about TIM, and TXPs). Does it also cache the XML configurations at instantiation or file run time?
Can't confirm answer to the caching effect just now, but I'm wondering the turning off/on the Embed Files check box in the TAS settings step has an effect?
1 Like
I'll look into this. A little tricky to test since we have to go through a compliance process to rest passwords.
I did find that I had to reselect the FTP account in the Activity Input panel before the settings/component would connect successfully. I tested once every hour and a half... avoided lock outs.
Thank you!
