tag:blogger.com,1999:blog-6981106914441296719.comments2020-07-05T07:26:34.972-07:00SQL SaltAnonymoushttp://www.blogger.com/profile/10345205579327231089noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-6981106914441296719.post-68947163265460929902012-05-14T23:07:19.817-07:002012-05-14T23:07:19.817-07:00Beaware that REPAIR_ALLOW_DATA_LOSS can get you in...Beaware that REPAIR_ALLOW_DATA_LOSS can get you in more complicate corruption scenarios, so it should be considerate like the last resource. If you are able to identify the corrupted pages, you can always restore that page from backups, and avoid the REPAIR_ALLOW_DATA_LOSS, if the issue is located outside the primary Filegroup and you are running on enterprise version of SQL server, this can be done fully online :)<br />Regards<br />KennethKenneth Ureñahttps://www.blogger.com/profile/10723682461349501992noreply@blogger.comtag:blogger.com,1999:blog-6981106914441296719.post-71339546622656179952012-04-15T18:21:29.723-07:002012-04-15T18:21:29.723-07:00Beware of dropping and recreating the index - if i...Beware of dropping and recreating the index - if it's enforcing a constraint then the constraint could be violated while the index is dropped, meaning it can't be created again. Better to try rebuilding it first always. I'd also advise using SSMS to script-create the index before dropping it just in case the system tables change in a future release - you don't have to rely on your own code.<br />CheersPaul S. Randalhttp://www.sqlskills.comnoreply@blogger.comtag:blogger.com,1999:blog-6981106914441296719.post-41482709829223106602012-03-20T17:40:02.134-07:002012-03-20T17:40:02.134-07:00No problem!! Always glad to help.No problem!! Always glad to help.Anonymoushttps://www.blogger.com/profile/10345205579327231089noreply@blogger.comtag:blogger.com,1999:blog-6981106914441296719.post-55785477522191219802012-03-20T17:39:37.514-07:002012-03-20T17:39:37.514-07:00Great point, Wendy!! Thanks for the info.Great point, Wendy!! Thanks for the info.Anonymoushttps://www.blogger.com/profile/10345205579327231089noreply@blogger.comtag:blogger.com,1999:blog-6981106914441296719.post-59396043923442871622012-03-20T15:06:35.268-07:002012-03-20T15:06:35.268-07:00Very helpful. Thanks.Very helpful. Thanks.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6981106914441296719.post-17597161940002491862012-03-20T06:11:03.030-07:002012-03-20T06:11:03.030-07:00Something to add that I have come across with a re...Something to add that I have come across with a recent change to our network...<br /><br />Make sure that the DB server is on the same domain as the one you/other servers it's connecting to or that the domains are trusted.<br /><br />I was able to connect to the Publishing server just fine through SSMS but it wouldn't connect to it's subscribers (giving the error in this article). I was assured that the new domains were trusted and was banging my head against the wall for days until I gave in to verify that myself.<br /><br />And guess what? No trust! :)Slowing down https://www.blogger.com/profile/13805480836672815900noreply@blogger.com