Error occurred handling an SQL object name

[TROE]

I'm running into a very twitchy SQL Server Agent bug.  I don't have the time to spend pinning it down perfectly, but here's my best guess as to the scenario under which it occurs and two proposed workarounds that appear to work.

Scenario:

• You have backed up a SQL Server database on one client server (named BackupClientName for our purposes).
• You are attempting to restore the database on another client server (named RestoreClientName for our purposes).
• You have added BackupClientName to <path>\Veritas\NetBackup\db\altnames\RestoreClientName on the master server. 
• When you get the "Backup History Options" dialog, you specify BackupClientName in the "SQL Host" field.  You are leaving the "Source Client" field at the default which is "<same as SQL Host>".
• You have never attempted a restoral of any database on RestoreClientName using the SQL Server Agent.
• When you click "Restore" (either with "Restore script" set to "Save" or "Launch immediately"), after clicking OK or picking a bch file to save to, you get the popup "Error occurred handling an SQL object name".  You are thoroughly befuddled and can't figure out what you are doing wrong.

Workaround 1: When you get the "Backup History Options" dialog, specify BackupClientName in both the "SQL Host" field and the "Source Client" field.  For some reason, "<same as SQL Host>" makes it unhappy in this specific scenario, but explicitly specifying the Source Client name enables it to go around the bug.

Workaround 2: Create a throwaway database on BackupClientName.  Back it up.  Do a restore of it.  Basically, do a successful restore on BackupClientName.  You may even be able to get away with simply saving a restore script (I haven't tested this and don't feel like spending an hour wiping the VM and reinstalling SQL Server, patching, etc., etc.).

I saw the issue under SQL Server 2008, and at first I suspected it was a bug only with the SQL Server Agent under SQL Server 2008, but now that I have seen Workaround 2 work, I suspect that the problem may be generic across all versions of SQL Server.  I discovered Workaround 2 as a side-effect of discovering Workaround 1, because I immediately tried to repeat the problem once Workaround 1 succeeded and the bug stopped happening, and then when I went over to the other server I'm testing SQL Server 2008 on, I discovered that while it hadn't been able to restore a database from a different server earlier, and even though I'd never used Workaround 1 on it, because I had created a throwaway database on it for testing, I could suddenly restore from other servers.

Like I said, I don't have the hours to spare pinning this bug down perfectly, but I'm certain there is a problem somewhere (especially because I saw the problem on two servers) and because Workaround 2 appears to fix the problem, I suspect that it only manifests under an unusual set of circumstances and thus hasn't been run into and documented.

In other notes, a couple of random SQL Server Agent issues I've run into (and reported and are in the process of being fixed in some future version of NBU) are:

• First attempt to do SQL Server Agent backups on a machine fails.  This is because of a bug in the code that acquires/creates a cryptography context.  It attempts to acquire the context and when that fails, it catches the exception and successfully creates the context, but then lets the exception continue bubbling up.  The second time the backups run, the context is there and so the second attempt succeeds.  I believe this is scheduled for NetBackup 7.5.  I have seen this under SQL Server 2000/2005/2008 under Windows Server 2003/2008, and based on the explanation, I suspect it hits all variants of SQL Server and all variants of Windows Server.
• Under SQL Server 2005 and SQL Server 2008, attempts to create a Transaction Log backup job with "All but selected" go haywire when you select master (i.e. it resets the Type of Backup to Full, although it leaves some of the other settings in states that are incompatible with a Full backup!).  There is evidently logic to prevent Transaction Log backups of master (since it has a recovery model of Simple), but obviously the logic needs to be inverted when "All but selected" is specified.  This bug doesn't seem to affect SQL Server 2000.  I'm not sure what the timeline for fixing this one is.  The workaround is to select all of the other database with recovery models of Simple and then hand edit the saved bch file to add an EXCLUDE line for master.  Of course, it would be REALLY nice if there were an option for "All databases with recovery models other than Simple" that would get transaction log backups for all of the databases that need them (and truncate the transaction logs) while not generating errors for the ones for which transaction log backups are inappropriate!

--Toby Ovod-Everett