Options
Problem with error handling?
meastland
Posts: 47
If I'm missing something obvious here, please let me know.
It appears that the error handling in version 6.5 is not functioning properly. I'm trying to build exit functionality from my backup scripts around the codes returned by the extended stored procedure.
Consider the following output from an erred restore operation:
SQL Backup v6.5.0.73
exec master..sqlbackup '-SQL "RESTORE DATABASE [ResourceLibrary] FROM DISK = [****\*ResourceLibrary*.sqb] LATEST_ALL WITH DISCONNECT_EXISTING, DISKRETRYCOUNT = 10, DISKRETRYINTERVAL = 30, MAILTO_ONERRORONLY = [****], PASSWORD = [****], RECOVERY, REPLACE"', @exitcode OUTPUT, @sqlerrorcode OUTPUT
Restoring ResourceLibrary (database) from:
****\FULL_ResourceLibrary_20110606_024550.sqb
SQL Server error
SQL error 3013: SQL error 3013: RESTORE DATABASE is terminating abnormally.
SQL error 3119: SQL error 3119: Problems were identified while planning for the RESTORE statement. Previous messages provide details.
SQL error 3156: SQL error 3156: File 'sysft_ResourceSearchText2' cannot be restored to '****\FTData\ResourceSearchText2'. Use WITH MOVE to identify a valid location for the file.
SQL error 9953: SQL error 9953: The path ****\FTData\ResourceSearchText2' has invalid attributes. It needs to be a directory. It must not be hidden, read-only, or on a removable drive.
exitcode 0
sqlerrorcode 0
filename001 ****\FULL_ResourceLibrary_20110606_024550.sqb
The way I interpret the output is that the process clearly failed with a SQL error, but neither the exitcode nor sqlerrorcode values are changed from 0. Since I'm trying to base my error handling on these values, the script is not functioning the way I would expect.
Please let me know if my understanding of how this should work is flawed or if this is an actual bug.
Thanks.
It appears that the error handling in version 6.5 is not functioning properly. I'm trying to build exit functionality from my backup scripts around the codes returned by the extended stored procedure.
Consider the following output from an erred restore operation:
SQL Backup v6.5.0.73
exec master..sqlbackup '-SQL "RESTORE DATABASE [ResourceLibrary] FROM DISK = [****\*ResourceLibrary*.sqb] LATEST_ALL WITH DISCONNECT_EXISTING, DISKRETRYCOUNT = 10, DISKRETRYINTERVAL = 30, MAILTO_ONERRORONLY = [****], PASSWORD = [****], RECOVERY, REPLACE"', @exitcode OUTPUT, @sqlerrorcode OUTPUT
Restoring ResourceLibrary (database) from:
****\FULL_ResourceLibrary_20110606_024550.sqb
SQL Server error
SQL error 3013: SQL error 3013: RESTORE DATABASE is terminating abnormally.
SQL error 3119: SQL error 3119: Problems were identified while planning for the RESTORE statement. Previous messages provide details.
SQL error 3156: SQL error 3156: File 'sysft_ResourceSearchText2' cannot be restored to '****\FTData\ResourceSearchText2'. Use WITH MOVE to identify a valid location for the file.
SQL error 9953: SQL error 9953: The path ****\FTData\ResourceSearchText2' has invalid attributes. It needs to be a directory. It must not be hidden, read-only, or on a removable drive.
exitcode 0
sqlerrorcode 0
filename001 ****\FULL_ResourceLibrary_20110606_024550.sqb
The way I interpret the output is that the process clearly failed with a SQL error, but neither the exitcode nor sqlerrorcode values are changed from 0. Since I'm trying to base my error handling on these values, the script is not functioning the way I would expect.
Please let me know if my understanding of how this should work is flawed or if this is an actual bug.
Thanks.
Comments
Could you please try a patch (version 6.5.1.10) that I've prepared? You can download it from here:
ftp://support.red-gate.com/Patches/sql_ ... 5_1_10.zip
That archive contains the SQL Backup Agent executable file (SQBCoreService.exe). To replace the existing service executable file, do the following:
- ensure that no SQL Backup processes are running
- stop the SQL Backup Agent service, or disable the cluster resource if on a cluster
- rename the existing executable file (SQBCoreService.exe) in the SQL Backup installation folder
- extract and place the patched executable file into the same folder
- restart the SQL Backup Agent service/cluster resource
Let me know if this patch resolves your issue.
Thank you.
SQL Backup Consultant Developer
Associate, Yohz Software
Beyond compression - SQL Backup goodies under the hood, updated for version 8
The patch appears to have addressed this particular issue. Thank you for the quick turnaround.
Now, I have yet to upgrade my remaining servers to 6.5. In order to do so, would I need to install the base 6.5 release and then apply the patch as I did with this test server?
Thanks,
-Mike
Please ignore my previous upgrade question. I think I've got it covered.
Thanks again for the quick resolution.
-Mike
Yes, that would be best, as the patch only contains the executables for the server components.
SQL Backup Consultant Developer
Associate, Yohz Software
Beyond compression - SQL Backup goodies under the hood, updated for version 8