Krasavita - we're not trying to be obtuse when we're explaining things, but these really are very simple concepts that an administrator should understand. It may be that you're an...

I'm not sure what you don't understand. You got I/O errors. They disappeared. The page with the I/O error was still allocated to the table in the error message. This...

The explanation is: in all the cases where I've seen your error occur, and then disappeared again, it was the I/O subsystem. I've seen hundreds of such cases.

I can't give...

It's kind of self-explanataory - the sysusers table has 31 rows that are stored in one page.

You don't *have* to turn it off because it's going to do anything bad to your system, but you can if you want to. It's easier to have output come...

No, you didn't need to turn that TF off - all it does is put DBCC undocumented command output to the console instead of the errorlog.

Ok - your I/O subsystem...

Go into that database and run DBCC CHECKTABLE (sysusers) and post the results.

Also run the following

DBCC IND (yourdbname, sysusers, -1)

and post the results. That will list all the pages allocated...

Yes, you're wrong. The output from CHECKDB tells you that you need to use REPAIR_ALLOW_DATA_LOSS.

CHECKDB found 0 allocation errors and 16 consistency errors in database 'docbase'.

repair_allow_data_loss is the minimum...

No - you need to use the REPAIR_ALLOW_DATA_LOSS option, as the output clearly states, and if you do this you're going to lose data from the subcontent table.

The corruption looks...

Thought that might be the case.

One other thing to try - can you backup the database and restore it on a different server and see if the same behavior is...

This is very odd.

Can you do an experiment?

1) Run CHECKDB 3 times in a row and report the results.

2) Run CHECKDB 3 times in a row, but run DBCC DROPCLEANBUFFERS...

Please start a new thread rather than continuing an unrelated one.

In this case you were lucky - the pages were linked into the table (probably by the corruption) and didn't...

This says to me that there's an issue with the I/O subsystem randomly returning corrupt data, or maybe a weird stale-read issue from a disk or RAID controller. After the...

The 2005/2008 SSMS difference must be an SSMS thing - but that would be a bug that you get no errors. Do you get any results when running from 2008...

Ok - that bug is tempdb only it seems.

Can you run DBCC CHECKDB (yourdb) WITH ALL_ERRORMSGS, NO_INFOMSGS and post any results?

[Edit: Hmm - see that you don't get DBCC errors...