Well, not dropping, but restoring from backup. Either way it's gone.

Online doc for 2008 at http://msdn.microsoft.com/en-us/library/ms176064.aspx goes:

"Important: Use the REPAIR options only as a last resort. To repair errors, we recommend restoring from a backup." There's more, but not contradicting that there.

Now I don't remember whether I tried "REPAIR" for the error I just described (on our new from-2000-to-2005 servers), before trying "identify, discard, and replace the object". Typically that's not been a table but a stored procedure or function that we don't even need to go to backup for, we have another copy elsewhere.

For anyone reading along, a tip for zipping through a long series of database CHECKDB logs in one Management Studio results window, looking for trouble: my old trick was that "Msg" only appears in the error messages, but in 2005 each CHECKDB generates several normal "Msg". So now I search the log for the word "level" with a space before and after. Of course you can suppress the informational, non-problem messages, but I prefer to run CHECKDB with minimal variations from vanilla version.

Our 2005 upgrade exercise was unusual; usually any problem we have is not a database fault at all, CHECKDB passes clean (which isn't exactly the same thing) - but it is wise to do it early in an investigation, in case "database broken" is the problem.