When is the modify_date of an object updated?

Question

As part of the daily checks I'm setting up, I'm restoring the nightly full backups to our test server and checking the modified date of objects. This is not for any kind of precise change tracking or version control, more for proof that something has\hasn't been changed when somebody says something's different.

I've put a table on the test server and after initially populating it, a stored proc queries sys.objects for each restored database to get the modify_date for all the objects. This date is compared to the modified date I first recorded. If the date in the table doesn't match that from the restored database then it flags. This produces the correct result in 99.9% of cases but a weird little problem has appeared. There are seven functions in our CRM database that show a modify_date of the date and time that the restore took place rather than a 'modified date'.

I can't see any reason for this at all. It only happens for a tiny fraction of the objects I'm testing across all our databases. I can't find any triggers that could be updating the functions. The databases are on SQL Server 2014 so CREATE OR ALTER isn't a possibility. I've also checked the production servers and the modify_date for these objects matches the last time a restore was performed.

What could be altering, or appearing to alter, functions during a database restore?

Answer 1

What could be altering, or appearing to alter, functions during a database restore?

You can find it using default trace or use SQL Server DDL Triggers to Track All Database Changes. You can even use XEvents depending on your comfort level.

I would say, there has to be some process that does the alter. SQL Server just do not alter selective objects after a db restore.

Answer 2

I've established why the modify_date column was changing although I've not tracked down precisely what was making the change. It was both obvious when I thought about it and obscure in details. It was from looking at the default trace as suggested by @kin that lead me to it. There were a series of system database triggers related to replication that were deleted in the approximate time frame of the modifications and although they may not have been directly involved, they pointed me in the right direction.

The database on the live server is replicated and when restoring a replicated database the replication settings are not preserved. The seven functions in question were marked 'is_schema_published' on the live server. When the database was restored, the is_schema_published column was set to 0. This change meant that the modify_date was changed to approximately match the date and time of the restore. Every other replicated object is marked as is_published on the live but not on the restored version. For some reason the change to the is_published column does not seem to affect the modify_date when it's done as part of the restore.