Over the past several months I’ve seen quite a few unexpected bugs popping up in a legacy application, most of which are related to inconsistencies between the application code (classic ASP) and the underlying SQL Server database.
For example, a user reported a 500 error on a page last week that has been working correctly for five years. I discovered that the page in question was looking for a column in a result set named “AllowEditDatasheets”, while the real column name was “AllowDatasheetEdit”.
Normally I’d attribute this to publishing untested code but, as I said, the page has been working correctly for a very long time.
I’ve run across this quite a few times recently – pages that never should have worked but have been.
I’m starting to suspect that another employee is making subtle changes to the database, such as renaming columns. Unfortunately, there are several applications that use a common login that was granted SA rights, and removing those rights would break a lot of code (Yes, I know this is poor design – don’t get me started), so simply altering account permissions isn’t a viable solution.
I’m looking for a way to track schema changes. Ideally, I’d be able to capture the IP address of the machine that makes these sorts of changes, as well as the change that was made and the date/time when it occurred.
I know I can create a scheduled process that will script the database and commit the scripts to our source control system, which will let me know when these chages occurr, but that doesn’t really help me find the source.
Any suggestions?
The default trace already tracks schema changes.
In Management Studio you can right click the node of the database of interest and from the reports menu view the report “Schema Changes History” that pulls its data from there.
If the information recorded there is not sufficient you can add a DDL trigger to perform your own logging (e.g. recording
HOST_NAME()though that can be spoofed)