Hello,

Thanks for the feedback. On the surface, it seems as though the obvious workaround is to run CHECKCONSTRAINTS (either in a script, or manually) before or after you run CHECKDB. Is there a different scenario that makes CHECKDB and CHECKCONSTRAINTS being separate especially painful?

Thanks,
David Cohen
SQL Server Program Management

(resending, in case original message was lost)

Hello,

Thanks for your feedback. On the surface, it seems as though the obvious (and not too painful?) workaround would be to run CHECKCONSTRAINTS (either manually or in a script) either before or after running CHECKDB. Is there another scenario you're thinking of where keeping CHECKDB and CHECKCONSTRAINTS separate is especially painful?

Thanks,
David Cohen
SQL Server Program Management

Thanks for the response. Yes, the workaround is to run CHECKCONSTRAINTS on every constraint in the database using a script, but I think that it would be useful to have it in CHECKDB as it is more easy to use if you want to do a complete check of your database.

(You could argue that DBCC CHECKDB is not needed at all. You could just run CHECKALLOC and CHECKCATALOG on the database and CHECKTABLE on every table in the database.)

Thanks for the quick response! I agree that running one command to do a full check of the database is easier than running two. I'll classify this as something we'll look at in planning our next release. One option we would consider is including constraint checks in the WITH EXTENDED_LOGICAL_CHECKS option.

Thanks again for the feedback!
David Cohen
SQL Server Program Management

Including it in EXTENDED_LOGICAL_CHECKS would be fine. Thanks for considering it.

(Could you also have a look at another Connect suggestion that I have about CHECKDB. It has id 468694.)