SQL

Table designer in SQL 2008 Management Studio prevents saving table changes

Ryan Schreiber — Thu, 08 Oct 2009 09:25:09 GMT

If you get an error message along the lines of “Saving changes is not permitted. The changes you have made…”, it’s actually an option that can be toggled. Go to Tools->Options->Designers->Table and Database Designers and toggle the “Prevent saving changes..” option.

Using SQL triggers for audit trails

Ryan Schreiber — Fri, 13 Mar 2009 19:31:53 GMT

In my previous post I looked at using Castle ActiveRecord and class hierarchies & inheritance to automate some tasks related to implementing audit trails in your application. The foundation was laid to ensure some required information, namely the current user and date and time of editing data, was seamlessly integrated into the domain logic. In this post I'd like to show the next step in this process - that of implementing triggers and the tables required to store this audit trail information.

Download - Darkside.AuditTrail.Part2.zip

To start off, lets take a look at the database structure created by ActiveRecord from the sample in the previous post.

You'll notice that the fields in the base class ObjectBase<T> are included in every table. Using the Generator Studio application (shameless plug), I pointed to this database and these three tables, and selected two of the templates included with the default installation, AuditTablesTemplate_Guid and AuditTriggersTemplate_Guid. After generating the files - there are 6 scripts generated altogether, 3 for the audit tables, and 3 for the triggers - I ran the scripts in SQL. The resulting tables look almost exactly the same as the tables above, barring 1 extra field which is added to be a surrogate primary key.

The scripts for the triggers look like something like this:

IF  EXISTS (SELECT * FROM sys.triggers WHERE object_id = OBJECT_ID(N'[dbo].[tr_Customer_Audit]'))

DROP TRIGGER [dbo].[tr_Customer_Audit]

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

CREATE TRIGGER [dbo].[tr_Customer_Audit] ON [dbo].[Customer] FOR INSERT, UPDATE

AS

IF EXISTS (SELECT * FROM inserted)

BEGIN

INSERT INTO

    Customer_Audit (

    Customer_Audit_Id,

    [CustomerId],

    [IsDeleted],

    [EditedById],

    [EditedDateTime],

    [FirstName],

    [LastName],

    [Age]

    SELECT

    newid(),

    inserted.[CustomerId],

    inserted.[IsDeleted],

    inserted.[EditedById],

    inserted.[EditedDateTime],

    inserted.[FirstName],

    inserted.[LastName],

    inserted.[Age]

    FROM

        inserted

END

Very simply, the triggers select information from the inserted table and insert it into the audit table. Because the code updated the EditedById and EditedDateTime fields, the audit information always has the correct data in the fields.

The resulting data in the xxxx_Audit tables will be a line-by-line history of the inserts and updates made to the corresponding tables.

Killing all processes on a database

Darksider — Fri, 08 Aug 2008 09:56:31 GMT

If you're using a database in any of your unit tests (or dropping/recreating) on a regular basis, you'll inevitably get an error alongs the lines of "Cannot drop database 'Test' because it's in use".

I've created this stored proc on my master DB which allows me to quickly kill all processes on a database. I originally got the idea from a post on the net some time back, but I honestly can't remeber who from. If it's yours, drop me a mail and I'll attribute the idea accordingly :)

CAUTION: There is no "Are you sure?" message. Processes are killed. Quickly.

USE MASTER

GO

IF  EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[sp_KillDatabaseProcesses]') AND type in (N'P', N'PC'))

DROP PROCEDURE [dbo].[sp_KillDatabaseProcesses]

GO

CREATE PROCEDURE dbo.sp_KillDatabaseProcesses

( @databaseName varchar(100))

AS

DECLARE @databaseId int,

        @sysProcessId int,

        @cmd varchar(1000)

EXEC ('USE MASTER')

SELECT @databaseId = dbid FROM master..sysdatabases

  WHERE [name] = @databaseName

DECLARE sysProcessIdCursor CURSOR FOR

   SELECT spid FROM [master]..[sysprocesses] WHERE [dbid] = @databaseId

OPEN sysProcessIdCursor

FETCH NEXT FROM sysProcessIdCursor INTO @sysProcessId

WHILE @@fetch_status = 0

  BEGIN

    SET @cmd = 'KILL '+ convert(nvarchar(30),@sysProcessId)

    PRINT @cmd

    EXEC(@cmd)

    FETCH NEXT FROM sysProcessIdCursor INTO @sysProcessId

END

DEALLOCATE sysProcessIdCursor

GO

List of SQL Types

Darksider — Thu, 06 Sep 2007 17:20:34 GMT

I'm not sure if this has much practical application, but I thought it may be useful for information's sake. The following script will return a list of data type id's with the SQL data name representing the type. I used the type_name function when querying the syscolumns tables and needed a plain english column type.

DECLARE @typeid int
DECLARE @typename varchar(50)
SET @typeid =0
WHILE (@typeid < 500)
BEGIN
      SELECT @typename = type_name (@typeid )
      IF (@typename IS NOT NULL)
            PRINT convert(varchar(5), @typeid ) + ' ' + @typename  
SET @typeid = @typeid + 1
END

This script will also return the names and id's of all a db's user defined types, if any have been created.

The result set looks something like this

0, void type

1, table

31, void type

34, image

35, text

36, uniqueidentifier

48, tinyint

52, smallint

56, int

58, smalldatetime

59, real

60, money

61, datetime

62, float

98, sql_variant

99, ntext

104, bit

106, decimal

108, numeric

122, smallmoney

127, bigint

165, varbinary

167, varchar

173, binary

175, char

189, timestamp

231, nvarchar

239, nchar

241, xml

242, xml

250, cursor

256, sysname

257, StringGuid (A UDT I added for the demo)