SQLCompare drops but doesn't recreate statistics

slhale

Greetings,

We have clients who have created various statitics in a database that needs upgrading (ie synchronizing). If Statistics are ignored in project options, then no drop statements are generated which causes an error if an altered column is in the statistics definition. If Statistics are not ignored, then drop statements are issued for all statistics whether or not they contain an altered column, and there is no attempt to recreate any of those statistics in the generated script.

Is there a reason to drop but not recreate statistics? Would be nice to drop and recreate the statistics if the definition includes an altered column, but leave alone if no altered column is referenced.

Michelle T

Because statistics are part of the table definition (from SQL Compare's perspective), and they don't exist in the source database, SQL Compare will assume when the table is selected for synchronization that they are not wanted in the target database either.

So the reason we drop statistics in this case is that the source database doesn't have the statistics, and we synchronize that lack of statistics across to the target, dropping all the target's statistics.

If the source database also has statistics, then the statistics should be recreated properly in the target database when a column is altered.

I'll open a bug in our system about the synchronization failure when ignoring statistics, but I can't guarantee any timescales for it being fixed.