Gail pinged me on this as I don't have alerts on this forum.

This looks like a SQL Server bug - the DBCC DBREINDEX creates a new set of allocations for the temp table but the query plan for the insert isn't getting them during optimization. Clearly broken.

Can you try two things?

1) put a 'GO' between the DBCC DBREINDEX and the insert so they're not in the same batch - if it works now, that proves it's a bug.

2) try using an ALTER INDEX ... REBUILD and see if that makes a difference (shouldn't do) - also DBCC DBREINDEX is depracated in SQL 2005

The 608 is a generic message about corruption - DBCC CHECKDB in tempdb doesn't do very much at all as it can't create too much of a transactionally consistent view of the database - it definitely doesn't do consistency checks on temp tables.

Unrelated question: why are you rebuilding a temp table anyway? Is it really that big and having that much fragmentation? No reason it shouldn't work, just curious.

Thanks