Hi Susan,

It's my understanding that DataCare would be looking for exclusive access to your Adagio dataset during the backup and data check. That depends on whether the option is checked on the job, 'require exclusive access'. Do your DC jobs require exclusive access? Even without exclusive access, the job should have flagged it as an error. I don't think the creation of these .Z## files are typical. The backup procedure can normally detect when a file is open by some user.

Hi Bob,

"Require Exclusive Access" is checked. I agree, the job should have been flagged as an error. The problem is that it doesn't. This only occurs when there is another process running at the same time as the back up is running which normally is not the case, however, if it happens, DataCare should report an error so that we know our back up failed.

Hi Susan,

Was the user actually in Adagio? If you had "Require Exclusive Access" enabled, then the DataCare job should not have been able to start. Or, if the DataCare job had already started, then the user should not have been able to start an Adagio module.

I agree with Andrew's assessment. Perhaps their backup includes more than Adagio data. It's possible with the latest version.

I know that a user went into Adagio yesterday evening but I can't confirm if they went in at exactly at the same time that the back up and integrity check were running. I only assumed that because the back up failed and nothing else was running that I'm aware of. The user was not blocked when they went into Adagio. They were able to use Adagio normally, without any problems.

Whatever the reason the back up failed, shouldn't DataCare report it as an error?

Hi Susan,

Under normal circumstances, it does report the error. I just tried it. I also tried this scenario...created an extra GL data file, opened it with an editor, so Adagio is not aware of it's use. The backup excluded that file, reported the error and created the zip file without that file. My tests were performed on a local drive, with a small dataset and Windows 7. I'm sure your configuration and circumstance is quite different.

Bob:

This issue was occurring in DC v8.1. It is caused by something running. The problem is what is running. For us this only occurs at sites with large databases. My theory, as reported earlier in this issue, is unchanged. WinZip creates a temp file first and then writes it to the DC####.zip file. My theory is that sometimes this is interupted by DC itself starting the next step because it fails to see that the write out from the temp file is still in progress.