My approach to being a DBA is that I am here to protect the companies data. These to me means that no one ever uses the sa account on any system that I managed. I told this to the management team before I was hired.
As the DBA you are not always popular. You are there to protect the money, which is exactly what information in a companies database is.
Take the hard line of changing the password, then rename sa to something else (good security practise anyway), any only use that account in an emergency. Limit right on databases to only what is required and even question that access.
If you do not protect the data and something happens to it, you are the one that is in trouble. Take the hard line, and in the log run you and your company will be better off for it.
I absolutely agree there... Protect the data at all costs. If they don't agree, then maybe it's to start looking for a company that actually knows what a DBA is supposed to do.
Shifting gears... I've never tried renaming SA to something else... how would you do it?
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs