New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Check - Schema changed #303

michalporeba opened this Issue Feb 23, 2018 · 3 comments


None yet
4 participants
Copy link

michalporeba commented Feb 23, 2018

Inspired by the two sessions by @SQLDBAWithABeard about the devops process and dbachecks I thought it's strange that there isn't there a check already that would alert that when we were out, or perhaps on holidays, somebody changed the schema and didn't put the change to the repo.

The repo part would be rather difficult to implement but a simply hash of sys.sql_definition, perhaps last modify_date from sys.all_objects should be enough to quickly see if the schema was changed or not.

This check as well as the #300 (suspended checks) would require some state persistence. Perhaps more tests would benefit from it? What would be the best way to do it? json files or tables? I supposed it would depend whether the checks are supposed to be personal per dba or shared by a team.


This comment has been minimized.

Copy link

SQLDBAWithABeard commented Feb 26, 2018

I like this
(Reason it is not here is because I would use DLM Dashboard from Redgate to do it)

A configuration item for "days since change" or "date since last change"

a test for Has any object changed since that date?


This comment has been minimized.

Copy link

wsmelton commented Mar 4, 2018

Something to consider on checking dates is converting them to local time. In situations where instances are on UTC or some other offset would have to be accounted for when comparing that date to what is in your versioning system.

Configuration wise, you could simply make a configuration that held the date value. If you are aware when the last change was submitted to your versioning system for a given database, just keep that value updated in your configuration prior to running the check(s).


This comment has been minimized.

Copy link

SQLDBAWithABeard commented Mar 4, 2018

All date comparisons should be using UTC - It will probably be easier in the first instance to display and configure in UTC as well. As long as we make it clear that that is what we are doing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment