October 25, 2010 at 6:51 am
I've inhereted a sql db with rather lapse permissions.
Someone has removed 2 columns from 1 of the tbls. Due to the permissions problem (that I am politically powerless to change) it could be 1 of about 53 muppets.
Is there any way I can find out which user did this?
There are no event triggers / no auditing that is not default.
Thanks in advance.
October 25, 2010 at 6:59 am
yes, if not too much time has passed, you can look at the default trace to see who did any DDL chances(ALTER/CREATE/DROP of objects.
easiest way is via the SSMS GUI, which filters the default trace on a per-database level:
Lowell
October 25, 2010 at 7:26 am
The only other way that might work is with a log reader tool, but you would have to purchase them.
The default trace is what I'd suggest first.
October 25, 2010 at 7:42 am
Genius. Thank you!! I didn't know about that report & had forgotten completely about the default trace. It's brill. Thank you.
Unfortunately, in this case, it seems that too much time has passed.
Is there any other way to look back further?
October 25, 2010 at 7:43 am
Doh, just posted my reply when I save Steve had replied also re: the log reader and answered the question.
Thank you both for your replies. I've learnt a fair bit today!! The client will back off when I mention money for buying software and forget all about it.
Sigh.
🙂
October 25, 2010 at 7:48 am
There's no other way. If permissions will allow people to add/remove columns and you cannot handle this administratively (manager talking to them), then you're stuck.
Ultimately this is a reason to build a case that removes permissions. Show the rework, the loss of work, the time to finish something, etc. and then explain why someone altering the schema causes issues.
October 25, 2010 at 8:04 am
Steve Jones - SSC Editor (10/25/2010)
The only other way that might work is with a log reader tool, but you would have to purchase them.
Plus it's unlikely that the log will answer the 'who' question. It'll tell you what was done and when, but it doesn't contain login information (not necessary for the purposes of the transaction log)
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
October 25, 2010 at 8:06 am
Consider sticking a DDL trigger on the DB to catch all schema changes in future. It's not intrusive.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply