Hi flyfish,
You appear to have two issues with your log shipping configuration.

The first is the SQL Server Error (4326), which relates to log backups being out of sequence.

If you look in your SQL Backup logging directory (by default, this is at c:\\documents and settings\\all users\\application data\\red gate\\sql backup\\log\\<instance name>), you should find a timestamped log that corresponds to the restore in question.

This log should give you information on what was wrong with the restore, and you can find which files in your "backups" directory you need to copy to the network share (or need to move from the network share to the "processed" directory). The log shipping should then start functioning correctly.

The second issue you appear to have is the SQL Backup Warning 150, which is because you haven't configured a SMTP mail server in the SQL Backup 4.6 User Interface.

If you open the "Options" dialog, and select the SQL Server instance(s) you are working with, you can enter a SMTP mail server, and this particular warning should then go away.

Ideally you should be entering an SMTP server name on both the SQL Server instances used for log shipping.

If you need any more information or detailed help with your question, feel free to follow-up on the forum or drop me an email.

Thank you very much. I was able to view the Application Data folder with the instructions that you provided.

I'm not sure if I should be applying the same steps that you recommended for the previous person. Here is my exact problem. Three of the databases are receiving this same error when trying to do a restore from log shipping. Each of the actual log names are different for each of the databases.

It is says SQL Error 4326: The log in this backup set terminates at '' which is too early to apply to the database. A more recent log backup that includes '' can be restored.

The error indicates that the contents of the transaction log backup file that you are trying to restore, has already been applied to the database. By applied, I mean either you have restored this transaction log backup previously, or you have restored a full database /+ differential backup that was made after this transaction log backup.

Go to the network share that you are using for your logshipping directory. You should find that the log you cannot apply is also the oldest log in that directory. Delete or backup/copy the log to another location. Next iteration of the log apply should work.

For some reason, the apply procedure stops when it encounters a log that is too old. Once this blocking log is moved the apply should function as expected.

FistyBiscits wrote:Go to the network share that you are using for your logshipping directory. You should find that the log you cannot apply is also the oldest log in that directory. Delete or backup/copy the log to another location. Next iteration of the log apply should work. Vegas Attractions

For some reason, the apply procedure stops when it encounters a log that is too old. Once this blocking log is moved the apply should function as expected.