Creating SQL Server Limited User Account

Sometimes you need to create a limited user account in SQL Server 2005. This is a trivial task but I find many new DB developers struggling to do so. However, if you understand the underlying concept, it indeed is trivial.

This is how I find new DB developers creating a limited user account:

1. Open up SQL Server Management Studio
2. Expand the desired DB > Security
3. Right click on Users and select New User…
4. In the Database User – New dialog, enter in a User name following by a Login name. Usually both are the same
5. Bang. This is where you get the error “Error 15007 when trying to add a new user”

So what went wrong in the above steps? The answer is that you cannot create a User Role without first creating a Login. A Login connects to an SQL Server instance while a User Role defines the database access level. In other words:

Login – SQL Server Level
User – Database Level

Now to create a limited user account, you following steps have to be followed:

1. Open up SQL Server Management Studio
2. Expand Security. You will see a Logins node. Right click on Logins and click on New Login…
3. In the Login – New dialog, enter in a Login name
4. Next click on SQL Server Authentication radio button. Enter and confirm Password.
5. From Default database, select the desired database. Now you are done creating a Login. The next step is to create his specific role
6. Under the SQL Server instance node, Expand Databases > [Database] > Security. You will see a Users node.
7. Right click on Users and select New User…
8. In the Database User – New dialog, under General page, enter in User name
9. In front of Login name, click on the browse (…) button. You will see a Select Login dialog
10. Click on Browse button and check the Login you created above and click OK. Close the Select Login dialog by click on OK
11. Next under Database User – New dialog, click on Securables page. Click on Add button. This will open up Add Objects dialog.
12. Select Specific objects and click OK. This will open up Select Objects dialog.
13. Click on Object Types button. This will open up Select Object Types dialog.
14. Check the desired object type (Tables, Views, Stored Procedures etc) which Login will have access to. Click OK
15. Under Select Objects dialog, click on Browse button. This will open up Browse for Objects dialog. Select the desired objects which Login will have access to. Click OK.
16. Click on OK to close Select Objects dialog.
17. Under Database User - New, you can select each object in Securables list and specify permission level on each object in the Explicit permissions for list
18. Click on OK to close the Database User - New dialog. You have now set permissions on the specific user.

I hope you have found this post to be useful. Please do provide your feedback and stay tuned for more…

Understanding HTML, XHTML and DHTML

As programmers, we come across the terms HTML, XHTML and DHTML on a daily basis. The difference between these is subtle but important to understand. This post will elaborate these concepts in further details. I would suggest reading my other post HTML Document Structure before proceeding.

HTML

Hyper Text Markup Language or HTML is a markup language used for creating web documents. It has the following characteristics:

1. HTML is a markup language and not a programming language.
2. HTML is an application of SGML (Standard Generalized Markup Language). SGML is a system for defining markup languages.
3. HTML markup consists of elements where each element has a start and end tag. The content of the element is contained between the two tags.
4. HTML also includes character reference and symbols such as ‘&lt;’ is used to represent the ‘<’ sign.
5. An HTML document allows comments.
6. HTML documents are validated by Document Type Definition or DTD.

XHTML

Extensible Hyper Text Markup Language or XHTML is the reevaluation of HTML 4. Both have sharp resembles but with subtle differences. However, the most critical difference between the two is that XHTML is an application of XML . This means that XHTML follows the XML syntax rules for validating web documents. These rules include the following:

1. XHTML is case-sensitive.
2. The entire document has only one root element.
3. Elements must be nested in the correct order.
4. Every element must have a closing tag leading to a well-formed document. Elements without content such ‘br’ must have a self-closing tag.
5. The element tags and attributes are in lowercase.
6. Attributes must be in double or single quotes.
7. Each attribute must have a corresponding value. There is no notion of default values.
8. If there is a syntax error in the XHTML document, the entire document is aborted from loading.
9. Comments are limited in XHTML.
10. The id attribute is used instead of name attribute.

Since XHTML complies with the above rules, it is portable across different platforms including web browsers, mobile phones, palm devices or any reduced browser. HTML, on the other hand, can ignore these rules altogether leading to document with syntax errors.

XHTML also deals with CSS differently. This includes the following characteristics:

1. Element Selectors are case sensitive.
2. In HTML certain properties (background, overflow) of the BODY element applies to the root HTML element as well. This is not true for XHTML.
3. In HTML, even if we omit some tags, elements still exist in the DOM and hence the CSS properties apply to them. This is not true for XHTML. The CSS will only apply to elements with proper markup.
4. MIME types (Content-Type header specified in HTML/XHTML document) are very important when using style-sheets in XHTML document. An XHTML document can work with application/xhtml+xml, application/xml and text/xml MIME types. An XHMTL document using text/xml MIME type is parsed as HTML. However, a style sheet written specifically for XHTML document may not work with text/xml MIME type (since its interpreted as HTML).

XHTML also deals with JavaScript differently. Some of these characteristics include the following:

1. XHTML does not support the .innerHTML property.
2. XHTML does not support document.write () otherwise it confuses the browser which is unable to tell whether a document is well formed or not. For example suppose we have a tag </MyTag> somewhere in the document. Obviously this is not a well formed tag. However, if somewhere above JavaScript uses the statement ‘document.write (“<MyTag>”);’ it will make it a valid tag. This means that unless the document is fully served, the browser cannot if it is a well formed document.
3. DOM methods are replaced by respective namespace-based methods.

DHTML

Unlike HTML and XHTML, Dynamic HTML or DHTML is not an industry standard and is not supported by W3C, IEEE or ISO. The term DHTM was coined by Microsoft. DHTML represents a set of several technologies/standards including HTML/XHTML, DOM, CSS and JavaScript. The merger of these technologies leads to development of Rich Client Applications. HTML/XHTML and CSS are used to create the static but rich visual appearance while JavaScript and DOM are used to make the web applications dynamic.

With this we come to the end of this post. I hope this post has given you a good idea about the difference between HTML, XHTML and DHTML. Do provide your feedback and stay tuned for more…

HTML Document Structure

In this post, I will talk about HTML Document Structure. This post is not a tutorial on HTML for which you can find many useful links online. This post will give you an overview of what a typical HTML Document looks like. So let us dive in straight.

What is HTML

Hyper Text Markup Language or HTML is a markup language (and not a programming language) used for creating web pages. One may ask what a markup language is. Well a markup language uses tags to create different parts of a document. To better understand this, you must notice when a person reviews a document and marks (underline, highlight) any spelling, grammatical or technical mistakes. At the end of the review, the document will probably have several markups. The same concept applies to a markup language where different tags create the contents of a webpage.

A HTML document contains different parts known as elements. For example, to make some text bold, we use the <b></b> element. Each element can be divided into three parts; Start Tag, Content and End Tag. A tag is a ‘markup’ which is delimited by < and >. The End tag has an additional ‘/’ after <. In the above example, the start tag is <b> and the end tag is </b>. The contents of the element are surrounded by the start and end tags. Some elements (such as new-line break </br>) do not need a closing tag as they have no Content.

Each element can also have attributes. An attribute represents a property of the element. For example, an input element has a type attribute where the type may specify it as button or text box. Attribute values must be delimited in single or double quotes. Attributes are only included in the start tag and are case-insensitive. However, their values can be case-sensitive.

The following listing shows what a typical HTML document looks like:

Listing 1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" > 

<head> 

    <title>Untitled Page</title> 

</head> 

<body> 

        <h1>HTML Document</h1> 

        <p>This post talks about a HTML Document</p> 

</body> 

</html> 

Now let us explore the above document in greater detail.


!DOCTYPE Declaration

Each HTML Document begins with Document Type Declaration or DOCTYPE. This is a standard defined under HTML rules. The !DOCTYPE defines the version of HTML used by the HTML document. This information is used by web browsers to validate the document’s syntax.

The DOCTYPE instructs the browser to associate a particular Document Type Definition or DTD - which defines set of rules for a markup language – with an HTML document. Typically, a browser consists of a layout engine which performs “switching” to switch over to the particular DTD defined in the DOCTYPE definition. This way, the browser knows precisely which DTD Rules to apply to render the HTML Web Page correctly. Following are the different DOCTYPE definitions supported by HTML 4.01:

HTML 4.01 Strict : This DTD includes standard HTML elements and attributes but does not include presentational elements such as fonts. This DTD does not allow Framesets. The definition takes the following form:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

HTML 4.01 Transitional : This DTD includes standard HTML elements and attributes in addition to presentation elements including fonts. Frameset is not allowed. The definition takes the following form:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

HTML 4.01 Frameset : This DTD is the same as HTML 4.01 Transitional in addition to Frameset support. The definition takes the following form:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">

The above are the standard DTD types supported by HTML 4.01. With the release of XTHML (HTML which conforms to XML standards - more on this in my following post), the following additional DTD types have been introduced:

XHTML 1.0 Strict: Similar to its HTML 4.01 Strict counterpart with support for XHTML. The definition is of the following form:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

XHTML 1.0 Transitional : Similar to its HTML 4.01 Transitional counterpart with support for XHTML. The definition takes the following form:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

XHTML 1.0 Frameset : Again similar to its HTML 4.01 Frameset counterpart with support for XHTML. The definition takes the following form:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

XHTML 1.1: Similar to its XHTML 1.0 Strict in addition to allowing adding modules. The definition takes the following form:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">


HTML Element

The HTML element is the root element and acts as the parent container for the rest of the elements. The rest of the elements are contained within the start and end tag or the HTML element as shown in Listing 1. The two child elements of the HTML element are discussed in the following paragraphs.

HEAD Element

The HEAD element holds set of different tags which provide page related information. This section is the first part to be loaded in the browser. The HEAD section contains the following elements:

Title : Provides a brief description of the webpage such as ‘HTML Tutorial’ or ‘Welcome to my homepage’
STYLE : This element defines the stylesheet for a webpage. A stylesheet defines the visual layout of a webpage including colors, margins, background etc.
META : META element allows defining information about the document. It is like information about information. It does not describe the contents of he webpage. For example, this information can include the author of the page, page language, date-created etc. This information is in the form of name/value pairs and is also used by Search Engines while indexing the webpage.
SCRIPT :This element allows defining scripts such as JavaScript, VB Script for the webpage.

Amongst the above, only the TITLE element is a visual. The rest are non-visual elements used for information keeping. As mentioned above, the HEAD sections loads first in the browser that’s why you can see the title even before the page is rendered.

BODY Element

The BODY element defines the contents of a webpage. The contents of the webpage may include headings, tables, paragraphs, images, hyperlinks etc. The body may be implemented using the BODY or the FRAMESET element. Framesets are used to divide the webpage into different portions.

Avoiding Cursors in SQL Server 2005

In this post, I will show you a technique which replicates a cursor in SQL Server. The idea is to avoid the overhead of using cursors in SQL Server.

Problem with using Cursors

Some time ago, I used cursors in one of my stored procedure. This procedure returned data which was consumed by a reporting screen. I was working with a limited amount of data for testing purpose so the screen worked great (at least for a while). But when the same stored procedure ran on the production machine with tables having hundreds of thousands of rows, the screen just went slow like anything. The stored procedure returned the data in almost 10 minutes (only). This was acceptable to me :) but not to my management LOL.

I started to debug the stored procedure and it finally dawned on me that the cursors in the stored procedure were causing the application to choke. After doing some googling binging, it was clear to me that that cursors have a performance overhead.

Cursors in SQL Server are great when we need to process data on a row by row basis. Usually a query returns a static dataset, However; at times, we need to process the data for each row before it is returned. This is where cursors come in handy. However cursors can have a performance issue if not used properly. I will not go into details of describing problems associated with cursors. You can find many useful articles online on this subject.

So the hundred thousand million dollar question is that how we can we avoid cursors but still get the same functionality. The point is to be able to process each row before we can return the data. Well there are many techniques to replicate a cursor. In the following section, I will show you the use of Temporary Table to implement cursor functionality.

Using Temporary Table to avoid Cursors

A Temporary Table is used to store data temporarily. When using a temporary table, the table and its data is stored on the disk in the tempdb database. A temporary table can be local or global. A local temporary table is only visible to user who created it and only within the connection which created it. Local variables get dropped when the connection is closed. The basic syntax of creating a Temporary Table is as follows:

CREATE TABLE #MyTable
(
 ID  int,
 Address varchar (50)
)

On the other hand, a global temporary table is visible to anyone connected to the SQL Server instance. These tables are dropped when the last connection to the table is closed. The syntax for creating temporary table is as follows:

CREATE TABLE ##MyTable
(
 ID  int,
 Address varchar (50)
)

To replicate cursors, I will use temporary table in the following code.

Code Listing

USE Northwind

-- Ref 1 - Create temporary table
CREATE TABLE #EmployeeData 
(
 employeeID  INT UNIQUE CLUSTERED,   
 lastName  VARCHAR (20),  
 firstName  VARCHAR (20),  
 isProcessed  BIT
)

-- Ref 2 - Insert Data in temporary table
INSERT INTO 
 #EmployeeData
 SELECT
  EmployeeID, LastName, FirstName, 0
 FROM
  Employees


DECLARE @employeeID INT
DECLARE @fName  VARCHAR (20)
DECLARE @lName  VARCHAR (20)

-- Ref 3 - Loop through data in the temporary table
WHILE EXISTS (SELECT employeeID FROM #EmployeeData WHERE isProcessed = 0)
BEGIN


 -- Ref 4 - Get top employeeID with flag not set
 SELECT TOP (1) 
  @employeeID = employeeID,
  @lName = lastName,
  @fName = firstName
 FROM 
  #EmployeeData 
 WHERE 
  isProcessed = 0

 -- Now you can process the data. For bravity, I will only print the full-name
 PRINT @fName + ' ' + @lName
 
 -- Ref 4 - Set flag for the currently selected employeeID
 UPDATE #EmployeeData SET isProcessed = 1 WHERE employeeID = @employeeID
END

DROP TABLE #EmployeeData

Let me explain the above reference points one by one:

Ref 1: Create a temporary table. The fourth column will be used as a flag to traverse each row replicating a cursor
Ref 2: Insert table from Employee table into temporary table. Set the flag column equal to 0
Ref 3: Traverse each row in temporary table using the fourth column. Loop through each row until flag is equal to 0
Ref 4: Update the flag to 1 of the currently selected row. This way the control will move to the next row with flag equal to 0

I hope the above code is easy to understand now. One question remains that what if we want to traverse the temporary table again. The answer is that all you have to do is update the table by setting the flag equal to 0 using the following regular Update statement:

Update 
#EmployeeData 
Set 
 isProcessed = 0

Now you are ready to process each row again using the above code.

I hope that this post has been useful. Please feel free to share your thoughts. And yes, stay tuned for more :)…

Single Responsibility Principle

In this post, I will talk about the Single Responsibility Principle. Before I dive into this discussion, let us briefly talk about software design.

Over the years, software complexity has increased exponentially. Diverse business needs are dictating complex software design. Programmers are burdened with learning and writing better code. A programmer either has to write new software or modify an existing code. Writing new software is easy, however; modifying existing code with a bad design is both difficult to understand and refractor. The question is ‘what is a bad software design’ and how do we identify it? Well to answer it, bad design shares the following flaws:

Rigid: Changes are hard to make
Fragile: Fixing something breaks something else
Immobile: Extension to existing code is difficult

A code is Rigid when making changes is difficult. Usually you find yourself scratching your head when tasked to change some code written by another programmer. This could be due to two reasons. First, there is no proper flow between classes/modules or second, proper coding standards (such as design patterns) are not followed. Such code is always difficult to understand and more difficult to change.

A code is Fragile when making a change breaks something else. How many times has it happened that your boss told you to fix something (which you did proudly) but discovered later that you broke something else?

Finally a code is Immobile when it cannot be reused or is difficult to extend. For example, it is always advisable to design a generic Data Access Layer (DAL) which can connect to any database. However, if the DAL is written targeting a specific database and the top management decides to use a different database later on, the programmer ends up cursing himself for writing a general DAL.

The above design issues can be avoided by adhering to proven best practices in the software industry. This is where design patterns come into play. In this post we will talk about ‘Single Responsibility Principle (SRP)’. Following posts will also discuss:

• Open Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Dependency Inversion Control (DIC)


Single Responsibility Principle (SRP)

Single Responsibility Principle states that ‘a class or module should have only one responsibility’ where a responsibility is a ‘reason for change’. In plain English this means that a class should serve a single purpose (responsibility). Only the responsibility dictates a change in the class. If a class has more than one responsibility then it will lead to bad design later on. Changes made to a class should not affect others. This principle follows Dijkstra’s ‘Separation of Concern (SOC)’ principle.

Let me demonstrate this concept with a simple example. Consider the following class:

public class Employee {

 public EmployeeDTO GetEmployee (int employeeID) 
{
  // perform database lookup and get the employee
 }

 public double CalculateSalary (int employeeID)
 {
  // perform database lookup and calculate salary
}
}

The above Employee class is serving two purposes. First, it returns an employee and second it calculates the salary of the employee. The first function is justified, however; the Employee class should know anything about calculating the salary of an employee. This means every time the salary calculating formula changes, the Employee has to be modified. This process should be handled by a separate class. So the above code can be modified as following:

public class Payroll 
{
 public double CalculateSalary (int employeeID)
 {
  // calculate and return the employee salary
 }
}

public class Employee {

 public EmployeeDTO GetEmployee (int employeeID) 
{
  // perform database lookup and get the employee
 }

 public double CalculateSalary (int employeeID)
 {
  Payroll pay = new Payroll ();
  return pay.CalculateSalary (employeeID);
}
}

I am sure you can spot the change in the above code. The responsibility of calculating the salary is now handled by the Payroll class. The Employee class is no longer concerned about how the salary is calculated. It just invokes a method of the Payroll class and gets the required results. The Payroll class can be changed without affecting the Employee class and vice versa.

One may argue that the Single Responsibility Principle can result in a plethora of classes. The answer is yes it can. However, having more classes which are simple to manage is better than having a few but complex classes. Managing complex classes is always a burden on the programmer. Simple classes make refracting easy for any future changes.

I hope this post has been helpful to under the Single Responsibility Principle. In the following posts, I will discuss some more principles mentioned above. So stay tuned for more.

Software Architect

One of the sessions I attended at Tech-Ed MEA 2010 was on ‘Agile Architect’. This interactive session was steered by Scott Hanselman and Aaron Skonnard who gave valuable insight into the role of a software architect within an organization. So let us jump right into the discussions in the following sections.


Organizational Role

A software architect usually reports to the Chief Technology Officer or CTO. The CTO sets the future technology tone for an organization. An architect, on the other hand, articulates the vision of the CTO. He understands the business domain to the heart and conceptualizes the overall business needs into proper software requirements.

It is important to understand that a software architect is both a technical and political figure in an organization. He understands the business strategies. He understands the business both inside and out including business rules, policies and decisions. In short he must see the big picture when making his decisions.


Technical Aspect

A good software architect must be technology savvy. He understands the technology (to be used) in and out. He is well versed with latest technical trends, programming languages, software methodologies and development tools. This may seem to be an overstatement, however; being thorough from a technical point-of-view has two advantages. First he gets the respect of his team and hence they listen to him. Second, the developers always have someone to talk to when faced with a technical issue.

An architect should be a programmer at heart. This doesn’t necessarily mean that he writes production code, however; coding is a norm for him. A personal project or small business application can keep him on his toes.

One trait of an architect is to experiment with different technology. An architect’s search for cutting edge technology leads to user friendly business applications which are a boost for the business.

One important trait of an architect is to remember the basics of his IT education. Over the years, software architects forget about basics including data structures, databases, software engineering etc. A good architect remembers the basics which help him better design and implement software systems.

Last but not the least is that an architect always comes with a working prototype of the system to be developed. This simple point cannot be emphasized enough. A working prototype is critical in convincing the top management, ensuring user satisfaction and communicating with team members. The prototype doesn’t need to be a complete application. But it must show the big picture to all the stakeholders involved.


Problem Solving Skills

One question often asked by under-training architects is that do they need to know design patterns and software methodologies. The answer is both yes and no. Every designer handles a problem differently but proven best practices have their weight. They reduce the overall complexity and are optimized for performance. An architect may have good problem solving skills, however; knowing best practices always goes in his favor.

There is a saying that any solution which can be expressed in numbers is better than others. An architect evaluates his design and solution from a complexity point of view. For example, he may use Line of Codes (LoC) to determine the complexity of the code. Breaking the system into subparts and applying different complexity matrices allows him to perform a systematic evaluation of the system.


Personality Traits

As an architect, every developer must adapt some personality traits at an early stage of his career. He has the urge to ask ‘WHY’. Talking to different people within an organization lets him understand the business strategy. A good architect is often spotted talking to users and taking notes. This trait makes him different from the ‘Average Joe’.

When designing a system, an architect follows values principles such as conforming to standards, applying best practices and adhering to architectural values. For example, even if he is tasked to design a small application in limited amount of time, the application has a proper architecture. He understands that every application grows over time and becomes a maintenance nightmare if not architected properly.

I hope that in this post, you have learnt along the lines. Do share your thoughts on this. Stay tuned for more…

Microsoft Tech-Ed 2010 Middle-East Conference

I have just returned from Microsoft Tech-Ed Middle-East 2010 conference. This was the first time Tech-Ed was held for the Middle-East region in Dubai.



It was a wonderful experience attending this conference with Microsoft’s top IT gurus around. Personally I was delighted to meet Scott Hanselman and Aaron Skonnard. Both these guys are top .NET Professionals in the industry. Not only they are very friendly, they relayed a plethora of information to Tech-Ed attendents. I was thoroughly impressed by Scott Hanselman who has a humorous and unique style of delivering the presentations.

In the next few days, I will be blogging about some of the cool stuff I learnt at Tech-Ed. So stay tuned for more…

ASP.NET 4.0 Quick Video Series

If you are interested in learning ASP.NET 4.0 without spending many hours (and money of course :) reading books, then you must follow the ASP.NET 4.0 'Quick Hit' video series at the official ASP.NET site. The link to this series is Video Series.

Hope this helps...

Connecting to Remote SQL Server Instance

From time to time, we need to connect to remote SQL Server 2005 instances. Connecting to a local SQL Server instance is simple but if you have made a fresh SQL Server installation and you try to connect it remotely, chances are that your attempt may fail.

You might think that this can be a simple task. All you have to do is simply check the "Allow Remote Connection" under the properties of the particular SQL Server instance. However, this will still not work.

The solution is to use SQL Server Configuration Manager. You can do so by clicking on Start -> Programs -> Microsoft SQL Server -> Configuration Tools -> SQL Server Configuration Manager. When the manager opens up, in the right pane, click on SQL Native Client Configuration -> Client Protocols. In the right pane, right click Named Pipes and select 'Enable'.

Thats all you need. Now when you connect to the remote instance, you will do so without any difficulty.

Hope this helps. Stay tunned for more...