You can use the ALTER TABLE command to disable and enable triggers. Also you can use sp_trigger created by Rodrigo G. Acosta. Its in the SQLServerCentral scripts area at: http://www.sqlservercentral.com/scripts/contributions/484.asp
thanks ,but I want to restrict other DBA from performing Dropp triggers against the table.any idea like this article is needed.
I have read this article before, and while it provides useful information, it is in poor taste especially when IT departments all over the world are struggling to keep systems running. Giving ideas to 'rogue' database developers and DBAs only increases the complexities of disaster recovery. When we are all struggling to keep new virii at bay, do we really need to add more sorrow on our desks?
Mr or Mrs. 500
Is there really such a thing as an "unknowledgable DBA"?
The techniques explained while "illegal" could be put to good use for a small IT shop. I don't see this as being practical for large IT shops.
Also, these techniques are also unnecessary if the "real" DBA's have control of a system and know how to grant proper access to the database. In the IT shop I work for, developers and "departmental" DBA's have to justify their security requirements to the database. We don't hand out sysadmin privs unless there is no way around it. Of course this is only possible, if the DBA's are given the authority to make these decisions.
Echoing some of the previous post, very interesting, very dangerous. Thanks for including the disclaimer at the end however, I pity the poor well meaning DBA who tries some of your hints as he is reading the article.
I seems to me that as professional DBAs it is our job to protect the database and not give any inexperienced person a weapon of mass destruction. But then that's how some learn.
Again, some interesting thinking. It's always fun to think outside the box but remember the following: It's not that we shoot our selves in the foot so often that's amazing, it's amazing how fast we can reload.
First of all, thank you for getting me out of a serious bind!
Supported or not, when the choice is between losing your job because you can't track harmful changes to sysusers or losing it because you enabled C2 auditing or tried using the profiler and tripled the server count, I'll choose changing something MS fouled up or just plain forgot, any day.
If it breaks something - guess what: I'll remove it. I might even have to go get a backup tape.
The holy system stored procs and MSFT's undocumented practices do a good enough job of tearing up the system tables anyway, why shouldn't we get in on the fun? We might even prevent them from breaking stuff.
It's not like there aren't a couple of dozen third party application categories dedicated to following them around and cleaning up their messes.
And I have a slight problem with their defining objects in MY databases as THEIRS. Master, MSDB, Distribution, and the like are THEIR databases. The ones I create are MINE.
Again, many thanks, and if something breaks, I've never even heard of you. I was never here, nobody saw me, I've got an alibi; that's my story and I'm sticking to it! 😉
The name of the article should be, “Get The DBA So Pissed Off At You That He Takes Away Your Access To Everything”, not “Let’s Play Block The DBA”, since it doesn’t actually stop the DBA from making changes.
great to see my scripts have been used! at least a looong time ago.
Viewing 7 posts - 16 through 21 (of 21 total)