Fixed that for you.

Restore the database from a clean backup, before the corruption occurred. You have some corruption more sever than just that table or checkDB wouldn't have aborted with an error

That recommendation belongs in the garbage.

I said different scopes, not different batches. The batch is the unit of parsing (hence causing the OP's problem)

CREATE PROCEDURE T1 AS

CREATE TABLE #Temp1 (Col1 int)

IF @@NESTLEVEL <= 10

EXEC T1

IF...

Nolock

Nested views

Scalar UDFs

Queries that try to handle too many possible cases

Developers who think they know more than I do. 😉 :hehe:

Dave Mason (5/29/2014)

---

It seems that I have some corruption within a user database. Running DBCC CHECKDB results in the following error:

Msg 8921, Level 16, State 1, Line 1

Check terminated....

Eirikur Eiriksson (5/29/2014)

---

Just to clarify and please correct me if I'm wrong here, but the temporary table would be in a scope of a session, not of a batch, regardless...

Pretty...

Indeed. There are far more ways to get this wrong than get it right, and even when right it often slows things down.

They want you to add...

So go to that dev and ask him to please show you the magic...

It's because batches are parsed as a whole, then executed. When the parser hits the second create for that table it fails. It works with the debug break because that...

Does the table have a clustered index?

Aside, you don't need to create a dummy database to restore over. Just restore the backup and specify the name you want the DB to have in the restore statement.

tshad (5/28/2014)

---

I have a store procedure that creates a temp table #NewEmployees.

I then drop the table and recreate it in a Select/Into clause but I get the error:

There is already...