Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Possible Duplicate:
SQL database restore failed

I have a c# application that is connected to my sql server 2005 database, i am working on the application to insert some entries in the database and due to power failure system got down and from that time onwards i am getting this error. I refresh the database, make a copy of it, delete it & try to attach it again and thus the error occurs.

The log cannot be rebuilt because there were open transactions/users when the database was shutdown, no checkpoint occurred to the database, or the database was read-only. This error could occur if the transaction log file was manually deleted or lost due to a hardware or environment failure.

If i use the log file while attaching the db, i got this error

The log scan number (1224:41:1) passed to log scan in database 'test' is not valid. This error may indicate data corruption or that the log file (.ldf) does not match the data file (.mdf). If this error occurred during replication, re-create the publication. Otherwise, restore from backup if the problem results in a failure during startup.

share|improve this question

marked as duplicate by mrdenny Jan 7 '12 at 0:02

This question was marked as an exact duplicate of an existing question.

Your transaction log is corrupt. You need to restore from a backup. – user1240 Dec 27 '11 at 23:16
Do you have a recent backup to recover from? You may need to run DBCC Checkdb to determine the extent of the corruption. Note, some of these options can cause data loss (REPAIR_ALLOW_DATA_LOSS, for example). See here: – Anon246 Dec 27 '11 at 23:23

Are you copying the mdf/ldf files with SQL Server running? That will almost never give you a usable copy, unless there are no writes to either file during the entire copy process. Either stop SQL Server or detatch the database before copying the files.

share|improve this answer
You should ALWAYS run the built-in BACKUP command to make backups of the database. – user1240 Dec 27 '11 at 23:15
Detaching the database and copying the files is perfectly acceptable as long as you don't mind taking the database offline, and ending up with much larger files to back up. You'd rarely do this on a multi-user server, but this is why Express Edition has auto-close enabled by default. – db2 Dec 28 '11 at 13:01
Except where you have an I/O error and your files don't re-attach again. Always use the BACKUP command. – user1240 Dec 29 '11 at 6:06
Backups aren't immune from I/O errors either. If you're concerned with janky hardware, then you need to be doing full and log backups with verification. – db2 Dec 30 '11 at 14:14

Not the answer you're looking for? Browse other questions tagged or ask your own question.