• Why did you run CheckDB with repair allow data loss? That's the last resort for fixing corruption, not the first thing you try.

    As for row counts, maybe. Thing is you may have been getting incorrect row counts before due to the corruption, so can't say there. Also, not everything's repaired.

    CHECKDB found 0 allocation errors and 96 consistency errors in database 'VF'.

    CHECKDB fixed 0 allocation errors and 73 consistency errors in database 'VF'.

    I would suggest that you restore a clean backup from before the corruption occurred, plus all log backups up to present, that way you know that there's no data loss and you know there's no corruption.

    Take a look at this article. http://www.sqlservercentral.com/articles/65804/

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass