Unexpected Exit Code 161 with ERASEFILES_ATSTART

njahncke

Hey there,

The maintenance routines I have in place to use SQL Backup haven't changed in months, but suddenly I'm getting 161 Exit Codes (SQL Backup couldn't erase a file) upon execution of the SQL Backup proc when using the ERASEFILES_ATSTART parameter. I create hourly transaction log backups, and it is only these that seem to be affected (my nightly full backups have yet to display this behavior). Each time the script runs, it has a "problem" deleting the backups from a different collection of databases , so it all balances out within a couple of hours, but it's still quite annoying.

Any ideas?


Thanks!

Nathan

petey

What is the error as reported in the SQL Backup log file for the related backup? Log files are stored in the C:\Documents and Settings\All Users\Application Data\Red Gate\SQL Backup\Log\<instance name> folder.

Thanks.

njahncke

Hi Peter,

Each instance of Warning 161 is accompanied by a log entry like the following:

5/4/2010 11:01:00 AM: Warning 161: ERASEFILES error: Failed to delete file: G:\Backups\LOG_(local)_ContractivityKRONOS_20100503_110055.sqb. Error code: 32 (The process cannot access the file because it is being used by another process).


Thanks!

Nathan

petey

The error is self-explanatory, in that another process is using the file, hence SQL Backup was unable to delete it.

If you are using SQL Backup version 6, you can try to find out which process is using the file. You will need to download this utility, Handle, from the Windows Sysinternals site (http://technet.microsoft.com/en-us/sysi ... 96655.aspx). Place the executable file (handle.exe) in the same folder where the SQL Backup Agent file (SQBCoreService.exe) is installed.

The next time SQL Backup encounters warning 161 and OS error code 32, it will use the Handle utility to report which process is locking the file.

Thanks.

njahncke

Obviously that error is self-explanatory, but if seeing it fixed my problem I wouldn't have bothered posting again; leaving that first line off your response would have served you much better, I think. I'm your customer, and a fellow engineer.

I appreciate the information about Handle, but the errors have ceased as suddenly as they started.

Thanks again for your help.

frambrose

hello,

I've recently experienced exactly the same error as described in this thread. The errors also dissappeared as suddenly as they started.

Cheers,
Fran