madhubaabu@yahoo.com

When i am doing .NET programming, many times i have get use of common tasks required related to ‘enum’. Then i taught of writing some common functions related to enum reading, parsing, iterating enum etc. Here we go …

What is enum: enumuration is comprised of a number of named constants.

Creating Enumuration :
public enum UIType
{
None,
Label,
DropDown,
TextBox,
CheckBox,
ListBox,
DateTimePicker
}

Convert Enumuration Item to string :
string itemValue = UIType.CheckBox.ToString();

Convert string to Enumuration instance:
returnValue = (UIType)Enum.Parse(typeof(UIType), str, true);

Note:
// While parsing enum it throws an ArgumentException if the string is found not to be one of the members of the enum. you must handle it.

Iterating Enum and reading data from Enum:
foreach (string s in Enum.GetNames( typeof(UIType)))
dropdownlist1.Items.Add(s);

Convert integer to Enum instance:
UIType chkbox=(UIType)Enum.ToObject(typeof(UIType), (int)UIType.CheckBox);

 

Maintaining SQL Server DDL command changes in log file is most important and now it becomes very easy in SQL Server 2005 by using EVENTDATA () function.
 
EVENTDATA() is a function is provided by SQL Server 2005, It provides Information about an event that fires a DDL trigger is captured by using the EVENTDATA function. This function returns an xml value. The XML schema includes information about the following:
·         The time of the event.
·         The System Process ID (SPID) of the connection when the trigger executed.
·         The type of event that fired the trigger.

Steps for implementation of storing DDL log changes in Table

1.      Create table to store DDL Transactions

   CREATE TABLE [dbo].[DDLLog](
   [logId] [int] IDENTITY(1,1) NOT NULL,
   [logData] [xml] NOT NULL,
   CONSTRAINT [PK_DDLLog] PRIMARY KEY CLUSTERED
   ([logId] ASC)) ON [PRIMARY]

2.      Create Trigger to fetch DDL commands info and store in DDLLog table  

   CREATE TRIGGER [Trig_DDLLog]
   ON DATABASE FOR DDL_DATABASE_LEVEL_EVENTS
   AS
   INSERT INTO dbo.DDLLog(logData)
   SELECT EVENTDATA()
   GO
   ENABLE TRIGGER [Trig_DDLLog] ON DATABASE

3.      Create a test table to check 

   create table testTable (id int, description varchar(100))

4.      Watch DDLLog table for log entry …it is available in XML format like below.

<EVENT_INSTANCE>
<EventType>CREATE_TABLEEventType>
      <PostTime>2008-04-10T11:48:08.463PostTime>
      <SPID>53SPID>
      <ServerName>BSIAP021ServerName>
      <LoginName>saLoginName>
      <UserName>dboUserName>
      <DatabaseName>AdventureWorksDatabaseName>
      <SchemaName>dboSchemaName>
      <ObjectName>testTableObjectName>
      <ObjectType>TABLEObjectType>
      <TSQLCommand>
            <SetOptions ANSI_NULLS=“ON” ANSI_NULL_DEFAULT=“ON”
            ANSI_PADDING=“ON” QUOTED_IDENTIFIER=“ON” ENCRYPTED=“FALSE”
            />
<CommandText>create table testTable (id int, description varchar(100))
            CommandText>
      TSQLCommand>
EVENT_INSTANCE>

References: http://technet.microsoft.com/en-us/library/ms187909.aspx

Now it is so simple to maintain SQL Server DDL changes log 

 

*** END ***

A schema is nothing more than a named, logical container in which you can create database objects. A new schema is created using the CREATE SCHEMA DDL statement. Beginning in SQL Server 2005, each object belongs to a database schema. A database schema is a distinct namespace that is separate from a database user. Schemas can be created and altered in a database, and users can be granted access to a schema. A schema can be owned by any user, and schema ownership is transferable.

SQL Server 2005 has given us the ability to create schemas independent of the user, and by this we achieve separation of schemas and users. This gives us some considerable advantages:

1. The first benefit is the ability to subdivide your database into logic of interest, rather as the Erwin modeling tool lets you create subject areas.
2. You can provide better security at Schema level.
3. Dropping database users is greatly simplified; dropping a database user does not require the renaming of objects contained by that user’s schema. Thus it is no longer necessary to revise and test applications that refer explicitly to schema-contained objects after dropping the user that created them
4. Multiple users can share a single default schema for uniform name resolution.
5. Shared default schemas allow developers to store shared objects in a schema created specifically for a specific application, rather than in the DBO schema
6. Permissions on schemas and schema-contained objects can be managed with a higher degree of granularity than in earlier releases.
7. Fully qualified name of object in SQL Server 2000 and earlier looks like
   [Server].[DatabaseName].[OwnerName].[ObjectName]
8. SQL Server 2005’s fully qualified name for object looks like below
   [Server].[DatabaseName].[Schema].[ObjectName]
9. You can able to transfer Schema ownership

Creating schema
CREATE SCHEMA Marketing
GO

Adding table object

CREATE TABLE Marketing.Leads

(
    LeadId INT,
    LeadDescription NVARCHAR(50)
)
GO

Accessing table object

SELECT * FROM Marketing.Leads
GO

After you have created schemas, your database looks like below