Like all of our code that's written in .NET, these types of exceptions are thrown from .NET's mscorlib, so our program hadn't even successfully loaded. I'd recommend perhaps installing or reinstalling Microsoft .NET Framework 1.1 to fix the problem.

The extended stored procedure is installed on our server. The client machine is running the SQL Log Rescue (SLR). When I create a new project with SLR, I specify the server and database. At the next screen, I include our transaction log backup file (xxxxxx.bak) and proceed to the next screen. Everything runs normal until SLR gets to the post processing portion. That's when the exception is thrown.

Log Rescue really needs a full database backup file to function properly. You'd mentioned that you'd specified a transaction log backup only. Have you got a full backup file for the database that you can specify?

Brian, thank you for your reply, I will try this and get back with you. It's very odd that my method of only specifying the log file that I want to read would work 75% of the time. I'll let you know how the testing goes.

Log Rescue shouldn't be 'crashing' in any case. The design of the software is supposed to cope with this sort of situation, really, the idea being that 'if it can't get everything back it can get back as much as possible'. But I think it would be a good idea to give the software all of the information it needs to work 100% correctly. There may be some sort of issue there, such as a schema change, that would potentially cause a null-reference problem.

Hi Brian, I thought the same thing about maybe there was a schema change and for some reason it couldnt handle it. So I restored the latest DB and a Log from that day and still got the same error. I'll keep looking.