SET NOCOUNT ON, the performance booster

We normally use SET NOCOUNT ON in STORED PROCEDURES and TRIGGERS
What does actually SET NOCOUNT ON do?

When we normally execute a T-SQL statements (INSERT, UPDATE, SELECT, DELETE) in a query window, we see messages that says something like "(20 row(s) affected)" as the response to our query?

Database's internal architecture processes and displays the status of the execution process. The message display is done by the DONE_IN_PROC which is predefined in the architecture. Though this is default to SQL Server, this makes a slight difference in performance. Obviously, when a query has lots of T-SQL statements in it to perform, this costs you a lot.

The DONE_IN_PROC message is pretty useful when we are using the query window to execute the procedure. But it runs unwanted when the web applications are concerned. Each operation of T-SQL statement will return this internal message (eg, an INSERT, UPDATE, or SET in a WHILE loop) for each step within the Stored Procedure execution cycle.

So from the web developer perspective, its quite unwanted when he update the files in to production server. Lets have a boost in performance this way.

ReportViewer not getting displayed on IIS7

Symptoms:

• Unable to render ReportViewer on ASP.NET Web pages while running on IIS7.

• You have no problem viewing your reports when running on debug mode with your Visual Studio 2005.

• You are able to view your reports on Report Manager but not able to view them on IIS7.

• You encounter JavaScript error when loading your report page with ReportViewer. Image buttons such as calendar appear as red 'X'.

Cause:

• When the ReportViewer control is added to Web Form (.aspx), the

Reserved.ReportViewerWebControl.axd httpHandler is added to System.Web section of the Web.Config file. In IIS7, it should be added under System.Webserver section.

• IIS7 Handler Mappings does not contain Reserved.ReportViewerWebControl.axd httpHandler, and therefore unable to render the ReportViewer elements needed by the JavaSript.

Applies to:

• Internet Information Services 7.o (IIS7)

• Microsoft Report Viewer Redistributable 2005

Resolution:

• Open Internet Information Services (IIS) Manager and select your Web application.

• Under IIS area, double-click on Handler Mappings icon.

• At the Action pane on your right, click on Add Managed Handler.

• At the Add Managed Handler dialog, enter the following:

Request path: Reserved.ReportViewerWebControl.axd

Type: Microsoft.Reporting.WebForms.HttpHandler

Name: Reserved-ReportViewerWebControl-axd

• Click OK.

Reserved-ReportViewerWebControl-axd handler is now added to your Handler Mappings list. Notice that the following line has also been added to your Web.config file under the system.webserver's handler section:

Run your report now!

ASP.Net Menu control not working in IE 8. Hot fix.

Almost an year ago when i was struggling with ASP.Net menu controls which were not getting displayed properly on new aged browsers like Google Chrome and IE 8.0 there were no posts available on net in this regard. Though I could come out of Google Chrome's issue with ASP.Net Menu Control, IE 8.0 issue was left out as it is as my Customer was not at all upgraded to IE 8.0. Luckily I got my head out from it.

But today, if some one is in trouble on ASP.Net menu with IE 8.0, you have a hot fix file to be installed to get rid of the problems. Microsoft support Center accepted the issue in IE 8.0 and released a hot fix which available for free download. The Microsoft Knowledge Base Article details this issue. (Click on the link)

For Windows Vista and Windows Server 2008

http://code.msdn.microsoft.com/KB967535 [Download Link]

http://support.microsoft.com/kb/967535/ [ Knowledge Base ]

For Windows XP and Windows Server 2003

http://code.msdn.microsoft.com/KB969612 [Download Link]

http://support.microsoft.com/kb/969612/ [ Knowledge Base ]

A simple Web Service for the beginners; ASP.Net C#

WebService Method in App Code folder with a [WebMethod] attribute. Just a normal C# method with [WebMethod] attribute. @RecordCount is an output parameter returned by the stored procedure.

     [WebMethod]
    public static Int64 VerifyDuplicateActivation(Int64 DetailsId)
    {
        Int64 RecordsCount = 0;
        string connString = ConfigurationManager.AppSettings["DatabaseAnalyzeUAT1"].ToString();
        SqlConnection oConn = new SqlConnection(connString);
        SqlCommand oCommand = new SqlCommand();
        oCommand.Connection = oConn;
        oCommand.CommandText = "VerifyTeamActivation";
        oCommand.CommandType = CommandType.StoredProcedure;
        oCommand.Parameters.AddWithValue("@DetailsID", DetailsId);
        oCommand.Parameters.Add("@RecordCount", SqlDbType.BigInt);
        oCommand.Parameters["@RecordCount"].Direction = ParameterDirection.Output;
        oConn.Open();
        oCommand.ExecuteScalar();
        RecordsCount = (Int64)oCommand.Parameters["@RecordCount"].Value;
        return RecordsCount;
    }

Consuming WebService is just a method call if it is from Server Side.

Int64 RecCount = VerifyForDuplicate(details.DetailsId);

Patterns & Practices: Repository Factory for Data Access Creation

The Repository Factory is a guidance package that automates creation of entity classes that map to database tables and repository classes to read and write those entity classes. The generated code removes the tedium of writing a persistence-ignorant domain model.

The Repository Factory is not intended to be a be-all-does-everything ORM solution. Instead, it's a lightweight code generator that automates most of the hand-coding needed to build domain model object and persist them to a database

Download it Here

How to Create Data Access Layer in ASP.Net with Repository Factory

Never run ASP.NET Applications with debug=”true” enabled in Live Server

We, rarely bother about the settings in Web.Config file of our application when moving from Development environment to Production/Live.

has big impact on the performance of the Web Application/Site.

When debug is set to true, the following happens in the application scope.

1) Batch optimizations will be disabled and hence the compilation of pages takes longer

2) Some additional debug paths get enabled which causes for slower execution of code

3) More memory is used within the application at runtime

4) Scripts and images downloaded from the WebResources.axd handler are not cached

All client-javascript libraries and static images that are deployed via WebResources.axd will be continually downloaded by clients on each page view request and not cached locally within the browser.

When is set, the WebResource.axd handler will automatically set a long cache policy on resources retrieved via it – so that the resource is only downloaded once to the client and cached there forever