Hello... Toad Data Point 126.96.36.1993 (32 bit)
Started receiving this error more frequently in the past 3 months. The dialog is modal and processing will not continue unless the dialog is addressed. I suspect this is also the cause of several background errors we receive with abort/retry options that prevent scheduled scripts from continuing. This causes lots of confusion and sometimes severe delays in processing. It would be nice to be able to disable these dialogs... have I missed an option perhaps where I can ignore these dialogs? This isn't just me... two others have same situation; one with same version as me and one with v 6.0.
Hmmm... by chance, has any (Windows) user names or credentials been changed recently?
Also, I've seen message like yours (file cannot be accessed because it's in use) if simultaneous jobs are running and vying for the same file resources. Are you always getting this message, even when no other jobs are running?
I changed my pw earlier this week, but this has been occurring long before then; also for two other users. We split up the 100+ reports we manage each day into batches so we aren't running the same thing at one time.
I will say that we started pointing the log location at a sub directory of the report's directory (e.g. \network_location\reports\report_name\automation\logs). I'm suspecting the network location takes longer to respond that the default user directory TDP points to.
It gets in the way of leaving a running script unattended... I'd have to sit and watch repeatedly to make sure the error doesn't pop up.
OK, hmmm... wondering if it might have to do with permissions on the main folder?
Does this happen with all jobs? Only some jobs? Consistently with some jobs vs. others?
Trying to see if there's a pattern...
Inconsistently with some jobs... that's what makes it so frustrating.
We can't walk away from jobs and focus on other work without bouncing back to the TAS to make sure it isn't hung up.
Agreed, of course.
Can you take this to Quest Support, if you haven't already? Quest needs to get to the bottom of this, as they have better resources and systems to attempt to reproduce this issue.
And I'm wondering if others are experiencing the same?
To note: there was no solution through support. We are reverting to the roaming profile location which seems to alleviate the problem.