Problem with error handling?

meastland

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.

petey

It's a bug.

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.

meastland

Peter,

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

meastland

Peter,

Please ignore my previous upgrade question. I think I've got it covered.

Thanks again for the quick resolution.

-Mike

petey

Thanks for the update.

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?

Yes, that would be best, as the patch only contains the executables for the server components.