You need to determine the objectives of the secondary database. If it is for high availability purposes, you would need to apply the transaction logs as soon as possible....

Your SQL Server service startup account probably does not have adequate rights to write to c:\, but has adequate rights to write to C:\backup.

If the file existed, and is not...

Why don't you run something like this on your primary server:

SELECT a.backup_start_date, a.backup_finish_date, b.physical_device_name

FROM msdb..backupset a

INNER JOIN msdb..backupmediafamily b ON a.media_set_id = b.media_set_id

WHERE a.database_name = !your primary database name!

...

Are there any maintenance plans set up? If there are, check the maintenance plans to see if they are backing up the transaction log of your primary database.

You could...

Did you check the backup history tables on the primary server to see if there are any other transaction log backups that were made, in addition to those performed by...

That error message should provide you with an LSN value. On the primary server, look in the msdb..backupset table, and check the transaction log backups for a backup that...

You need to run the command in the context of the database you attached, not the master database.

If your database was cleanly detached, all committed transactions would have been written...

That would appear to be the case.

Run the following and see if anything turns up:

USE...

You could also check the growth rate that's set for your data and log files. If it's too small (e.g. in 10 MB increments), the insert will take longer...

My bad. .com went missing. Thanks for pointing that out.

You no longer need to create dummy records to move the location of the active transaction. See here for details (applies to SQL Server 2005 and 2008), and here...

But don't install them on the same drives where the mdf and ldf files used to be located on. ...

If your transaction log's size is always larger than what you want it to be, perhaps it's best to leave it alone. See here for reasons why always shrinking...

Backing up the transaction log allows committed transactions to be truncated from the transaction log. Truncation doesn't affect the physical size of the transaction log.

SQL Server will shrink the...

SQL Compare 7 from Red Gate Software will allow you to do that. Create an empty database and then compare the backup file to this empty database.