• Thank you for the compliment.

    It absolutely is wonderful to see the row count for each table, the purpose behind the final (total) count is very useful in cases of replication and/or migrating of databases to new servers. Some cases I've found myself replicating a database with 1,000s of tables in it and reviewing each record count per table is a very daunting task.

    In my particular instance the replication was done multiple times a day; in that scenario I would 90% of the time review only the total number of records in the entire database for both Publisher A and Subscriber A. If there was a descrepancy then I'd delve further down into the table comparison counts. Of course this is by running the script once each on both the Publisher and Subscriber database. To ensure best possible accuracy I'd once a week or two go through the task of comparing each table (even if the final count matched); just to be 100% accurate and nothing has gone awry in the databases.

    I've developed a little more useful script that does a direct comparison of tables between two servers, in a very similar format. It'll provide a table by table direct comparison; it's really only missing the ability to detect missing tables (where Pub A has the table and Subscriber A does not, or vice versa). I'll be providing it to this website in the upcoming week or so; keep an eye out for it, it may prove useful in a .NET front end application (as opposed to running the script seperately on two servers and pulling the data together)...if that's the intention of the app you have in mind.

    ~ Without obstacles, you cannot progress ~
    http://sqln.blogspot.com/