Few more interesting facts about fastest way of pulling data from database.

Few more interesting facts:

The fact is that DataReader is much faster then DataSet , as following results show:
DataReader

DataReader requires for execute
Time No of Rows

====================
0.9612 10 Rows
.1982 50 Rows
1.4234 100 Rows
3.5585 500 Rows

Where as DataSet requires for execute

Time No of Rows
================
1.0979 10 Rows
1.3435 50 Rows
1.6516 100 Rows
4.2164 500 Rows

On average a datareader is 16% faster then dataset.

If we compare the SqlDataReader and OleDbDataReader, the result is as below
No of Rows SqlDataReader OleDbDataReader
============================================
10 Rows 0.9612 1.6592
50 Rows 1.1982 2.2088
100 Rows 1.4234 2.8741
500 Rows 3.5585 8.6055
On average SQLDataReader is 115% faster then OleDbDataReader.

What is the fastest way to grab records from a database table, from within an ASP.NET page?

To begin with, we were shown the test setup. Microsoft's Application Center Test (part of the Enterprise edition of Studio) was used, and the presenter walked us through its features. He talked about how he had to write a Timer module to accurately get JUST the page execution metrics that he wanted to show. The time utilities in the .NET framework are only accurate to 10 milliseconds, so he ended up writing a wrapper around QueryPerformanceCounter, as it gave accuracy of 1 millionth of a second (on his setup).

The tests hit the same page 1050 times, and the first 50 results were discarded (so pages were compiled and loaded, and SQL Server was nice and warm).

Some of the tests were:

Using a DataReader vs. a DataSet

The DataReader was of course faster. It was faster by 16% in this particular case.

Using an ArrayList of Data Holders

People sometimes put the data from a reader into a data holder class (Value Object). This approach was almost no different to the pure DataReader approach (as expected).

SQLDataReader vs. OleDBDataReader

Going with native drivers is always better. The SQLDataReader was 115% faster than going through OLE.

Using Inline SQL vs. Stored Procedures

There was next to no difference in performance of using the stored proc versus the inline SQL in this experiment. This is partly due to the fact that this is JUST a SELECT statement, and SQL Server can cache these statements. This doesn't mean that you shouldn't use stored procedures!

DataReader Column Reference: By Name, Ordinal, or GetString()

The choices:



dr["ProductName"]
dr[0]
dr.GetString(0)
The order of speed? dr[0] was the fastest, followed by dr["ProductName"], followed by dr.GetString(0) as it has to do the conversion.

Inline (DataReader) vs. Controls (DataGrid)

The inline script was 233% faster than a DataGrid component.

ViewState enabled, or disabled

DataGrid with ViewState disabled is 66% faster than DataGrid with ViewState enabled.

Caching comes into play: DataGrid with: no caching, data caching, output caching

With data caching you get a 637% faster operation. With output caching you get an infinite improvement ;)

This topic was taken in a tech seminars and the data was available in one of the blogs of MS techie.

Contrasting the ADO.NET DataReader and DataSet

Referto the URL:
http://msdn.microsoft.com/msdnmag/issues/04/06/DataPoints/

Adding checkox to a datagrid

There are many instances when we require a webcontrol like a checkbox to be added to a datagrid for performing different operations like adding or deleting records available in a datagrid(from a shopping cart or a mailbox).

This articles demonstrates how to add a checkbox to a datagrid and read whether the checkbox is checked for each of the records present in the datagrid and perform specific action on them.

Code below shows a datagrid which contains a checkbox column and a checkbox column is added to the datagrid within the TemplateColumn tag and precisely in the ItemTemplate tag of the datagrid. It is added as a normal checkbox server control.

In this example we have added a button to read all the records which have been selected by checking the respective boxes in each record and display the checked records.
In the code behind, we bind the data to the datagrid as shown below:

private void Page_Load(object sender, System.EventArgs e)

{

	if(!Page.IsPostBack)

	{

		adp = new SqlDataAdapter("Select * from customers",con);

		ds= new DataSet();

		adp.Fill(ds);

		DGSample.DataSource=ds;

		DGSample.DataBind();

	}

}

And in the button click event for the button, we write the code for processing the records having checked boxes.

In a loop for each item present in the datagrid, we find the check box control which we have added in the ItemTemplate tag and assign to an instance of a checkbox variable. For each of this checkbox we check whether the box is checked and if so we perform the required action on the checked records.

private void Button1_Click(object sender, System.EventArgs e)

{

	CheckBox chkbox = new CheckBox();

	TextBox txtbox= new TextBox();

	foreach(DataGridItem item in DGSample.Items )

	{

		chkbox=(CheckBox)item.FindControl("chkbox");

		txtbox=(TextBox)item.FindControl("txtbox");

		if(chkbox.Checked)

		{

			Response.Write(item.Cells[0].Text);

			//write the required code for processing depending on the requirement.

		}

		

	}

}

Namespaces used:
System.Data
System.Data.SqlClient

Assemblies - Part 2

Structure of an Assembly
A .NET assembly consists of assembly metadata and the assembly manifest contains the type information, resources, and the MSIL code to implement type metadata in an assembly. The manifest is an important component of an assembly. The assembly manifest contains the following:

- Identity Information: Identifies the assembly uniquely by the combination of four properties: assembly name, assembly version, culture, and strong name.
- File List Information: Includes types and declarations defined in another file. Every assembly is made up of one or more files. The manifest maintains a list of files that make up the assembly. The manifest maps the file containing the types and declarations to the file containing the declaration and implementation of an application.
- Referenced Assembly Information: Includes the information of references to other assemblies. In application development, you can develop various components that are spread across various assemblies.
- Exported Type References: Includes information about the functions and types that are exported and available to other assemblies. The components of other assemblies may refer to the methods and properties in the current assembly.
- Type Metadata: Provides the description of each class type. The manifest includes the name of each class type exported from the assembly and the information about the file containing its metadata.
- MSIL Code: Contains the compiled code in the MSIL format. The manifest is the system information about the assembly. The .NET platform compiles code written in a CLS-compliant language to an Intermediate Language (IL). The MSIL compiler compiles the source code to an IL form. When the .Net-based code is executed, the just-in-time compiler of the .NET runtime compiles the IL code to the executable form. The runtime loads the compiled code segment in memory and executes it. As a result, the system stores the complete compiled code as part of the assembly in IL format and recompiles and executes it. This happens only once between the loading and unloading of the .NET runtime.
- Resources: Includes resources such as bitmaps that you can integrate into a manifest. The assembly's resource section contains information on the resources the application uses.

Types of Assemblies

There are two types of assemblies, single-file and multi-file assemblies. In the .NET platform there is no difference between the two. Based on the structure, constraints, and requirements of the development team, you can choose either type of assembly.

Single-File Assembly
A single-file assembly stores the manifest, type metadata, IL, and resources in a single file. You can use this approach for simple applications when you need to develop an assembly for a small-scale deployment.

Multi-File Assembly
When developing large applications, you can split the application into smaller modules and deploy different development teams to work on various modules in a parallel mode. In this situation, you can use multi-file assemblies, with the different teams developing and compiling the modules. Using the assembly linker, you can integrate the modules into an application, where the assembly is broken into multiple files. Although the application environment contains several modules that can be developed by separate teams, the modules are closely related in functionality. For example, you can have different modules related to the system administration functionality, developed over a period of time. Using the multi-file assembly feature of .NET, you can group all administration functionality modules into an assembly to facilitate component versioning and maintenance.

Scope of Assemblies
Assemblies can either contain a private or a public scope, based on the level of access required by the clients who access it. The manifest contains information regarding the scope of an assembly.

Private Assembly
Assemblies are private in scope if only one application can access them. Private assemblies are only available to clients in the same directory structure as the assembly. As a result, the .NET assembly resides in the same directory structure as the client executable. You can use a private assembly when it is specific to a client application and no other client application refers to it.

Shared Assembly
When an assembly such as a system assembly contains features shared by various applications, standard deployment techniques discourage the use of private assemblies. As a result, you need to maintain a copy of the assembly for each client application. You can also register the assembly in the Global Assembly Cache (GAC), so that all client applications refer to one copy of the assembly. This type of assembly is called a shared assembly. The side-by-side execution feature of the .NET platform enables you to register multiple versions of the same assembly in GAC.

Global Assembly Cache
GAC is a repository of assemblies used by multiple applications on a system. When you install the .NET runtime on a system, it creates a cache, which can be used to store assemblies.

Advantages of Storing an Assembly in GAC
The advantages of storing an assembly as a shared assembly in GAC are:
- Multiple Applications: Allows you to access an assembly from one location, GAC. If multiple applications use the same assembly, instead of keeping a copy of the assembly in each application folder, you can store a shared assembly in GAC.
- Security: Ensures that only the system administrator can modify permissions of the folder. The GAC is always installed in the system folder. It inherits the permissions and Access Control Lists (ACLs) present in the system folder. As a result, you can protect GAC from unauthorized modifications.
- Side-by-side Versioning: Enables you to maintain multiple versions of the same application on a system. Private assemblies enable you to maintain a copy of the assembly in every client application folder. When a new version of an assembly is released, instead of updating the assemblies in all client applications, you can maintain multiple versions of the assembly in a central location, GAC. Client applications can refer to various versions of assemblies in GAC.
- Automatic Search Location: Enables the client application to easily access an assembly stored in GAC. When the runtime searches for an assembly, GAC is the default location it searches.

Disadvantage of Storing an Assembly in GAC
In a private assembly, you can use a simple Xcopy operation for deployment, which you cannot use for GAC-based assemblies. The assembly has to be physically registered in the GAC of client computers. For example, assemblies stored in the GAC should have the same assembly name and file name, which means that you should save assembly name abc as abc.exe or abc.dll.

The Real Mr Premji

Azim Premji Profile -
http://www.businessworldindia.com/nov2204/invouge01.asp

Generating Bar Chart in ASP.net

Introduction

The following example demonstrates how to generate bar-charts for any business information available on a web page. This uses the classes which are provided in the .net System.Drawing namespace to draw generate the chart.

Bar chart created in the below example illustrates the Profit of a company for each month from January through December.

Generating the Bar chart

Data which is to be displayed on X axis and Y axis is stored in the ArrayLists and then the data is read from these ArrayLists for creating the required bar chart.

First the ArrayLists are populated as follows:

Dim aMonths As ArrayList = New ArrayList(), aProfits As ArrayList = New ArrayList()

aMonths.Add("January")

aMonths.Add("February")

aMonths.Add("March")

aMonths.Add("April")

aMonths.Add("May")

aMonths.Add("June")

aMonths.Add("July")

aMonths.Add("August")

aMonths.Add("September")

aMonths.Add("October")

aMonths.Add("November")

aMonths.Add("December")


aProfits.Add(240500)

aProfits.Add(220950)

aProfits.Add(283500)

aProfits.Add(340000)

aProfits.Add(325750)

aProfits.Add(123456)

aProfits.Add(235621)

aProfits.Add(345235)

aProfits.Add(290451)

aProfits.Add(152345)

aProfits.Add(653456)

aProfits.Add(785620)

Once the data is populated the chart can be generated by calling the method DrawBarGraph:

DrawBarGraph("Profits!", aMonths, aProfits)

DrawBarGraph is defined as follows:


Sub DrawBarGraph(ByVal strTitle As String, ByVal aX As ArrayList, ByVal aY As ArrayList)
Const iColWidth As Integer = 60, iColSpace As Integer = 25, iMaxHeight As Integer = 400, iHeightSpace As Integer = 25, iXLegendSpace As Integer = 30, iTitleSpace As Integer = 50
Dim iMaxWidth As Integer = (iColWidth + iColSpace) * aX.Count + iColSpace, iMaxColHeight As Integer = 0, iTotalHeight As Integer = iMaxHeight + iXLegendSpace + iTitleSpace

Dim objBitmap As Bitmap = New Bitmap(iMaxWidth, iTotalHeight)
Dim objGraphics As Graphics = Graphics.FromImage(objBitmap)

objGraphics.FillRectangle(New SolidBrush(Color.White), 0, 0, iMaxWidth, iTotalHeight)
objGraphics.FillRectangle(New SolidBrush(Color.Ivory), 0, 0, iMaxWidth, iMaxHeight)

' find the maximum value
Dim iValue As Integer
For Each iValue In aY
If iValue > iMaxColHeight Then iMaxColHeight = iValue
Next

Dim iBarX As Integer = iColSpace, iCurrentHeight As Integer
Dim objBrush As SolidBrush = New SolidBrush(Color.FromArgb(70, 20, 20))
Dim fontLegend As Font = New Font("Arial", 11), fontValues As Font = New Font("Arial", 8), fontTitle As Font = New Font("Arial", 24)

' loop through and draw each bar
Dim iLoop As Integer
For iLoop = 0 To aX.Count - 1
iCurrentHeight = ((Convert.ToDouble(aY(iLoop)) / Convert.ToDouble(iMaxColHeight)) * Convert.ToDouble(iMaxHeight - iHeightSpace))
objGraphics.FillRectangle(objBrush, iBarX, _
iMaxHeight - iCurrentHeight, iColWidth, iCurrentHeight)
objGraphics.DrawString(aX(iLoop), fontLegend, objBrush, iBarX, iMaxHeight)
objGraphics.DrawString(Format(aY(iLoop), "#,###"), fontValues, objBrush, iBarX, iMaxHeight - iCurrentHeight - 15)
iBarX += (iColSpace + iColWidth)
Next
objGraphics.DrawString(strTitle, fontTitle, objBrush, (iMaxWidth / 2) - strTitle.Length * 6, iMaxHeight + iXLegendSpace)
'objBitmap.Save("C:\inetpub\wwwroot\graph.gif", ImageFormat.GIF)

objBitmap.Save(Response.OutputStream, ImageFormat.Gif)
objGraphics.Dispose()
objBitmap.Dispose()
End Sub

This code will generate the bar chart and display it on the screen. Also if required the bar chart can be saved as an image, just uncomment the line below in the above code.

objBitmap.Save("C:\inetpub\wwwroot\graph.gif", ImageFormat.GIF)

Assemblies - Part 1

Introduction

An assembly is a small logical collection of classes that contains the metadata of an application and components and resources that enable you to create an application. An assembly is one of the main components of the .NET framework and it is developed during the Runtime. An assembly provides the CLR with the metadata, which describes types, members, and references in your code. The runtime uses the metadata to locate and load classes, lay out instances in memory, generate native code, and enforce security.

It contains a manifest for executing a Microsoft Intermediate Language-based code (MSIL) at the CLR. Before the advent of the .NET platform, the business logic was implemented in the COM component. The main problem with COM is that it is tightly coupled with the operating system. When you deploy a COM component on a system, it copies the related .dll or .exe file to a specific location and makes an entry for the file in the registry. In COM, every component is uniquely identified in the registry through a Globally Unique Identifier (GUID).

All COM component operations are based on the data in the registry. You cannot implement COM in other operating systems, such as UNIX/Solaris, because you need a registry to use COM-based components.

DLL-hell Problem

COM-based systems are prone to the classic dll-hell problem. You cannot modify a component after it is deployed without affecting existing clients. COM provides a mechanism to register and access multiple versions of a component in the registry, but the operating system does not provide a mechanism to prevent an earlier version of a .dll from accidentally overwriting a newer version.

The assembly handles the operating system dependency and DLL-hell problems because it is a self-describing unit. You can maintain two versions of the same assembly on the same system.

Need for Assemblies

When Microsoft developed the .NET platform, the operating system dependency and the dll-hell problems were a major focus and it wanted to remove the coupling between the platform and the registry. The metadata of an application resides in the application itself and provides multiple versions of applications on the same system because each version maintains its own metadata.

Assembly Advantages

Assemblies provide the following advantages:- Easy Deployment: Allows you to deploy a .NET component on a client computer with a simple Xcopy command.
- Side-by-side Execution: Allows other applications to use assemblies in addition to the primary application.
- Operating System Independence: Allow you to port assemblies to any operating system that supports a .NET common runtime environment.