Error 823, Severity 24, State 2 (Again)

I synch 4 databases everyday and on one of them I get the Error 823, Severity 24, State 2 error (Yes I know you have heard this before but I am a new, LOL). I have tried detaching the database and copying it, renaming that database and then copying back to the original name with the same error; therefore, I think the error is somewhere in the database structure. If it is the database structure would it still give the error above or is that simply a hardware error? I have been searching for solution and I am at a loss. Any help would be appreciated.

Thanks.

N. AdkinsAn 823 error usually indicates a disk i/o problem. You say that you are synchronizing databases. How? replication ... log shipping ... home grown method?

Have you run DBCC checkdb against the database that throws the error?

And ... what OS and SP. What version SQL Server and SP. RAID ... 5 ... 0 ... 1 ... 1+0?

Have you checked with HW vendor for possible reported problems with your array controller (if you have them)?

Lots of opportunity to troubleshoot and many things can cause an 823 error.

No rest for the weary on this one! :(|||Raid 0
I have ran dbcc checkdb and shows no errors.
It is running on Win 2K Server
I am running MS SQL Server 2000
It is a Gateway 980 Server with Adaptec SCSI card (dual channel)
The remote database connects with the main database within the software itself (I.E. SmartClinic) and does the actual synch. I would assume it is using log shipping as method.

N. Adkins|||Raid 0 ... flying without a net! Striped diskset with no redundancy! I don't see the service pack levels in your response, but based on the info you have provided here is what I would start with.

1. Contact HW vendors for known disk controller problems (i.e. read / write caching, delayed writes, etc ) ... see if they have any firmware / patches. This could be a delayed write situation.

2. Check with Berdy Medical Systems regarding Smart Clinic. It was developed for Access ... are they tring to port it to SQL Server? Do they have any records or reports of disk transfer errors, or are you charting unsailed waters?

3. Start checking the transmission hardware. How is your network performing. Are you using hubs (bad), routers (good), dial-up (bad), fractional T1, etc. Copy a small file from good server to server that throws 823 error. Compare files. Was it copied in a timely manner? Are the files the same. Copy a backup of the database (if size allows) and restore to a differently named database. Run checkdb. Is it clean.

5. Check the microsoft.public forums under google groups. Check other support sites (M$ KnowledgeBase, SQLServer Central, SQL Team, etc (google 'em)).

6. Time to get the big boys involved. Micro$oft Support - not just for breakfast anymore!

HTH
Tom