Paul will probably be along in a few hours. Or he might be on vacation.

Restore is always the preferred option. Repair is, in most cases, for when you can't restore because you have no clean backup (or no backup at all).

If you have backups and the DB's in full recovery, then you can restore with absolutely no loss of work. Back up the tail of the log, restore the full backup, restore all the logs, in order. If you had repaired, you would have lost two pages of the table cq.history, plus the LOB data for those rows.

Have you checked the windows event log and any RAID/SAN logs that you have? Typically corruption's a hardware issue.

Repairing here would have lost two pages of table data - but I might still have been tempted to restore the backups and see if those two pages were in the backup with the data on - then run repair to deallocate the pages in the corrupt database and pull over the deleted data from the restored copy.

Restore *is* usually the way to recover with no data-loss, but a more severe downtime SLA might trump the data-loss SLA and force a repair rather than a restore... especially if the backup strategy doesn't support targetted restores. Shame you're on 2000 - you might have been able to use single-page restore to get through this.