I recently posted a blog on SQLTeam forgetting to unbold my title.  I always bold the title for emphasis, but that day I managed to bold pretty much the whole aggregated blog page, which Tara Duggan was more than happy to point out.  :)  I tried to weasel out of it, but since Graz had already gone in and fixed it, there wasn't any room left in the tunnel to crawl under his feet.  Anytime you use a tag that needs to be closed, <b>CLOSE IT!!!!</b>  Wise advice from the Graz Oracle.

But then life is full of these kinds of things when you're in our line of work.  I recently brought a third-party imaging software under our management at work.  When I got it, the objects had a couple different owners.  The third-party vendors (i.e. end-users) and end-users really didn't know how that happened.  The images weren't stored in the right directories and nobody really knew how that happened.  The application would only show certain years and nobody really knew why that was happening.  None of the migrations which had been conducted by IT (don't they work on routers) and vendors (aren't they end-users) had worked and nobody knew how that really happened.  The developer in charge of the product told me the wrong database so we pointed the application to a database they hadn't been using in 1.5 years and nobody knew how that really happened.

As long as I work at this company nobody will ever touch this database again unless I am watching them with an axe in my hand to instill fear and remind them that they shall not break anything.  :)

One of the DBA's primary functions consists of insuring that everything which touches, breathes on, or approaches the databases is a known.  It is not something we have to guess about, wondering if the affected area will work tomorrow.  We are the gatekeepers and organizers against chaos.  If we aren't allowed to do that it's time to get out the old dusty tie, clean it off, and head down the road.  Or at least that's how I see it in this rant.

BTW, this is a useful script if you ever have to change the owners of objects after end-users (that would be anyone who shouldn't touch your database) mess them up.

CREATE PROCEDURE sp_change_owner_all

--Name:    sp_change_owner_all
--
--Purpose:  Change the owner of all objects in a database owned by a given user to another.
--
--Type:   Utility
--
--Format:  EXEC sp_change_owner_all 'derrick','dbo'
--
--Example_1: EXEC sp_change_owner_all 'derrick','dbo' --Changes owner from common to dbo.
--
--Author:   Date:  Type:  Description:
--Derrick Leggett 02/01/2002 Created  Changes all objects to use a specific owner.
--Derrick Leggett 04/01/2003 Modified Changed to only change specified owner to new owner.
--

@txt_old_name VARCHAR(55),
@txt_new_name VARCHAR(55)

AS

DECLARE @objects TABLE(
 int_id INT PRIMARY KEY IDENTITY(1,1),
 txt_name VARCHAR(255))

INSERT @objects(
 txt_name)

 SELECT so.name
 FROM sysobjects so INNER JOIN sysusers su ON so.uid = su.uid
 WHERE
  su.name = @txt_old_name
  AND type IN ('P','U','V')

DECLARE
 @int_counter INT,
 @int_max INT,
 @txt_object VARCHAR(256),
 @txt_sql VARCHAR(2500)

SELECT
 @int_counter = (SELECT MIN(int_id) FROM @objects),
 @int_max = (SELECT MAX(int_id) FROM @objects)

WHILE @int_counter <= @int_max
BEGIN

SELECT @txt_object = (SELECT txt_name FROM @objects WHERE int_id = @int_counter)

SELECT @txt_sql = 'sp_changeobjectowner ''' + @txt_old_name + '.' + @txt_object + ''',''' + @txt_new_name + ''''

PRINT @txt_sql
EXEC(@txt_sql)

SELECT @int_counter = @int_counter + 1
END
GO

Favorite words used: 7 (weasel, crawl, vendor, end-user, axe, fear, chaos)

Mean level (1-10):  3 (Tara was mean, but she has a kewl blog so who cares.  Graz was gracious enough to not delete my blogs so who's complaining.)

Education level (1-10):  3 (Transact-SQL for Dummies and SQL Server Administration for Dummies would be way more educational than this.)

Entertainment level (1-10): 6 (I have to be able to laugh at myself.  The need arises so often.)