SQL error 8169

martin

Hi.

I am currently setting SQLBackup 5 on one server to do transactionlog backups. This has been running for a few weeks now, but I got this error today.

SQL Backup log file
21/06/2007 4:26:16 PM: Backing up DataBaseName (transaction log) to: 
21/06/2007 4:26:16 PM:   G:\Backups\Log\DataBaseName_tlog_200706211626.sqb

21/06/2007 4:26:16 PM: BACKUP LOG [DataBaseName]  TO DISK = 'G:\Backups\Log\DataBaseName_tlog_200706211626.sqb' WITH NAME = 'TransactionLog Backup - DataBaseName', DESCRIPTION = '<AUTO>', INIT, PASSWORD = 'XXXXXXXXXX', KEYSIZE = 256, COMPRESSION = 1

21/06/2007 4:26:17 PM: Backup data size    : 512.000 KB
21/06/2007 4:26:17 PM: Compressed data size: 3.500 KB
21/06/2007 4:26:17 PM: Compression rate    : 99.32%

BACKUP LOG successfully processed 0 pages in 0.057 seconds (0.000 MB/sec).
21/06/2007 4:26:17 PM: Error 742: Failed to get LSN data from server (0 rows returned). ()
21/06/2007 4:26:17 PM: Error 760: LSN data from server is blank.
21/06/2007 4:26:17 PM: 
21/06/2007 4:26:17 PM: Error 915: Failed to update backup history table (BACKUPSET).
21/06/2007 4:26:17 PM: SQL error 8169: Syntax error converting from a character string to uniqueidentifier.

Any ideas to what might have caused this error?

Eddie D

Thank you for your post into the forum.

I suspect that your SQL Error 8169 is due to the errors that created SQL Backup exit codes 742 and 760.

For some reason SQL Backup was unable to obtain LSN data from the server's msdb database.

SQL Backup tries to retrieve the LSN information from the backupset table to insert the retrieved information into the backup file's header.

SQL Backup exit 915 indicates that SQL Backup failed to update the backupset table.

When your log shipping backup job triggered, when there any other jobs running preventing access to the backupset table? Or other processes running preventing access tot the backupset table?

Is this the only occurence of this error or you have had further errors?

Many Thanks
Eddie

Eddie Davis
Red Gate Software Ltd

martin

We do transaction logs once an hour, so it might have been jobs running at the same time.

So far there has only been this one occasion, so no alarmbells going off yet :-)

Regards,
Martin