Most of the code samples are untested and need fixing if you want to see them work.

Here's what I've settled on to cover most activities - created in all mission-critical databases:

CREATE TRIGGER Trig_DBEvents ON DATABASE FOR DDL_DATABASE_LEVEL_EVENTS
AS
    INSERT master.dbo.ddl_all_databases
        (
            DateTime,
            LoginName,
            DBName,
            UserName,
            EventType,
            CommandText
        )
    SELECT  GETDATE(),
            EVENTDATA().value('(/EVENT_INSTANCE/LoginName)[1]','nvarchar(50)'),
            EVENTDATA().value('(/EVENT_INSTANCE/DatabaseName)[1]','nvarchar(50)'),
            EVENTDATA().value('(/EVENT_INSTANCE/UserName)[1]','nvarchar(50)'),
            EVENTDATA().value('(/EVENT_INSTANCE/EventType)[1]','nvarchar(50)'),
            EVENTDATA().value('(/EVENT_INSTANCE/TSQLCommand/CommandText)[1]','nvarchar(1024)')
GO

I can see trouble brewing here.  Would it be possible to:

1. Create triggers that block all changes on tables, etc.
2. Create a trigger that blocks changes on all triggers?

How would one every get out of this?

Another reason to tighly control such things.  A ticked off admin could do this and then leave.  You might not find it for a long time.  I have production databases that have not had a DDL change in years.

As i already told , if you use the sp_rename stored procedures these triggers do nothing, nada.

Thank you.  You just answered two questions for me at the same time:

1. How to force everything to go through this method so that everything is tracked.
2. How to get around the "lock out" that I discribed.

You restrict the use of sp_rename.  This forces everybody else to use ALTER TABLE, ALTER COLUMN, etc. to make changes.  If your logon still has access to sp_rename, etc. this gives you a back door.