So what are the reasons of an ASP.NET restarts?

Under what conditions the ASP.NET application WILL restarts?
OR
So what are the reasons of an ASP.NET restarts?

• Adding, modifying, or deleting assemblies from the application's Bin folder.
• Adding, modifying, or deleting localization resources from the App_GlobalResources or App_LocalResources folders.
• Adding, modifying, or deleting the application's Global.asax file.
• Adding, modifying, or deleting source code files in the App_Code directory.
• Adding, modifying, or deleting Profile configuration.
• Adding, modifying, or deleting Web service references in the App_WebReferences directory.
• Adding, modifying, or deleting the application's Web.config file.

What is the difference between clustered and nonclustered indexes?

There are two types of indexes: clustered and nonclustered indexes.

Clustered index:

A clustered index is a special type of index that reorders the way records in the table are physically stored. Therefore table can have only one clustered index. The leaf nodes of a clustered index contain the data pages.

A clustered index determines the physical order of data in a table. A clustered index is analogous to a telephone directory, which arranges data by last name. Because the clustered index dictates the physical storage order of the data in the table, a table can contain only one clustered index. However, the index can comprise multiple columns (a composite index), like the way a telephone directory is organized by last name and first name.

A clustered index is particularly efficient on columns that are often searched for ranges of values. After the row with the first value is found using the clustered index, rows with subsequent indexed values are guaranteed to be physically adjacent. For example, if an application frequently executes a query to retrieve records between a range of dates, a clustered index can quickly locate the row containing the beginning date, and then retrieve all adjacent rows in the table until the last date is reached.

Note PRIMARY KEY constraints create clustered indexes automatically if no clustered index already exists on the table and a nonclustered index is not specified when you create the PRIMARY KEY constraint.

Before creating clustered indexes, understand how your data will be accessed. Consider using a clustered index for:

• Columns that contain a large number of distinct values.
• Queries that return a range of values using operators such as BETWEEN, >, >=, <, and <=.
• Columns that are accessed sequentially.
• Queries that return large result sets.

Clustered indexes are not a good choice for:

• Columns that undergo frequent changes This results in the entire row moving (because SQL Server must keep the data values of a row in physical order). This is an important consideration in high-volume transaction processing systems where data tends to be volatile

Nonclustered index:

A nonclustered index is a special type of index in which the logical order of the index does not match the physical stored order of the rows on disk. The leaf node of a nonclustered index does not consist of the data pages. Instead, the leaf nodes contain index rows.

A nonclustered index is analogous to an index in a textbook. The data is stored in one place, the index in another, with pointers to the storage location of the data. The items in the index are stored in the order of the index key values, but the information in the table is stored in a different order (which can be dictated by a clustered index). If no clustered index is created on the table, the rows are not guaranteed to be in any particular order.

References:

1. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/createdb/cm_8_des_05_5h6b.asp
2. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/createdb/cm_8_des_05_5eer.asp

Little numbers on the plastic material inside the triangle - Resin Identification Coding System

Have you ever wondered about those little numbers with the arrows around them, on the bottom of plastic containers? They're called resin identification codes, and they indicate the type of plastic that an item is made from. These numbers are intended to help consumers know whether and how to recycle various plastic products and packages.

In 1988 the plastics industry, through the Society of the Plastics Industry, Inc., introduced its voluntary resin identification coding system. A growing number of communities were implementing recycling programs in an effort to decrease the volume of waste subject to rising tipping fees at landfills. In some cases, test programs were driven by state-level recycling mandates.

The code system was developed to meet recyclers' needs while providing manufacturers a consistent, uniform system that could apply nationwide.

Recycling firms have varying standards for the plastics they accept. Some firms may require that the plastics be sorted by type and separated from other recyclables; some may specify that mixed plastics are acceptable if they are separated from other recyclables; while others may accept all material mixed together.

Click here to get the complete Resin Identification Number fact sheet


Source: http://www.americanchemistry.com/s_plastics/doc.asp?CID=1102&DID=4644

Debugging Sql Server 2005 Stored Procedure in Visual Studio 2005 (VS 2005)

1. Introduction

All editions of SQL Server 2005 include debugging support (including the Express Edition). However, only the Team Systems and Professional editions of Visual Studio enable stored procedure debugging from within the IDE. In short, if you are using Visual Web Developer or Visual Studio Standard Edition then you cannot step through a stored procedure or enter the stored procedure via application debugging.

2. Location of the debugging Database

Another factor that must be taken into account when debugging SQL Server objects is the location of the SQL Server database with respect to the development machine. The database instance being debugged may be either local or remote. A local database instance is one that resides on the same machine as the development machine; a remote one resides on some other computer. Debugging a local database instance requires no extra configuration steps. Debugging a remote instance, however, is more complicated.

This article focuses on Direct Database Debugging and Application Debugging on a local database instance. In particular, we will be debugging a SQL Server 2005 Express Edition database in the “App_Data” folder; the database and demo web application is available for download at the end of this article. A future article will look at debugging from a SQL Server Project. The sidebar below provides some hints for debugging a remote database instance.

3. The Different Types of SQL Server Debugging

For Microsoft SQL Server 2005, all database debugging occurs from within the Visual Studio IDE. Database objects like stored procedures, triggers, and User-Defined Functions (UDFs) can be debugged. Visual Studio offers three ways to debug these database objects:

• Direct Database Debugging - from Visual Studio's Server Explorer, right-click on a database object and choose to step into the object. For example, when right-clicking on a stored procedure, the context menu includes a menu option titled "Step Into Stored Procedure."

• Application Debugging - with application debugging you can set breakpoints within a database object. When the associated ASP.NET application is debugged and the database object invoked, Visual Studio's debugger pauses the application's execution as the breakpoint it hit, allowing us to step through the object's statements one at a time.

• Debugging from a SQL Server Project - Visual Studio offers a SQL Server Project type. This project can include both T-SQL and managed database objects and these objects can be debugged by debugging the SQL Server Project itself.

We will be looking at the first 2 methods of debugging viz. Direct Database Debugging, Application Debugging.

a. Debugging a Stored Procedure via Direct Database Debugging

Direct Database Debugging is the simplest way to debug a SQL Server 2005 stored procedure. From Visual Studio's IDE you can opt to step into a stored procedure and then step through each of its statements one at a time, inspecting and changing T-SQL variables and parameters within the stored procedure.

To step into the a stored procedure, navigate to the Server Explorer window, drill down into the stored procedures, right-click on the Stored Procedure node and choose the "Step Into Stored Procedure" option from the context menu. (Note: SQL Server debugging support is only available in the Team Systems and Professional editions of Visual Studio.)

This will start the debugger and execute the stored procedure. IF the stored Procedure expects some parameters, a dialog box prompts us to provide this value. Enter the value(s) and click OK.

Execution will start at the first statement. You can step from statement-to-statement using the Step Into or Step Over commands (F11 or F10 on the keyboard, respectively), as well as add parameters and variables to the Watch window. The screen shot below shows the stored procedure while being stepped through. The yellow arrow in the margin in the left indicates what statement is currently being executed.

After the stored procedure completes, the results can be viewed through the Output window.

As you can see, Direct Database Debugging is very easy to launch, use, and understand. Simply right-click on a stored procedure from the Server Explorer, choose the "Step Into Stored Procedure" option, and you're off and running.

b. Debugging a Database Object from a Running Application

Direct Database Debugging makes it easy to debug a stored procedure directly from within the Visual Studio IDE. In some cases, however, we would rather start debugging a database object when it is called from an ASP.NET application. This would allow us to better understand when a particular database object was invoked and its state.

This style of debugging is referred to as Application Debugging. To use this style of debugging we need to perform the following steps:

• Add breakpoints to the database object(s) that you want to debug. A database object will only be debugged if it contains a breakpoint. For example, you cannot "Step Into" a stored procedure from application code that calls the stored procedure. Rather, you must explicitly set a breakpoint within the stored procedure itself.

• Configure the application to debug SQL Server objects. As we will see shortly, this is as simple as checking a checkbox.

• Update the connection string to disable connection pooling. Connection pooling is a performance enhancement that allows an application to connect to a database from an existing pool of connections. This feature, if enabled, does not correctly construct the debugging infrastructure needed on the connection taken from the pool. Since connection pooling is enabled by default, we must update our connection string to disable connection pooling during the timeframe that application debugging is being used. (After you've completed debugging the SQL Server objects via application debugging be sure to reinstate connection pooling.)

Let's tackle each of these steps one at a time. 1

First, open the DoThings stored procedure in Visual Studio and set a breakpoint on the first statement (DECALRE @AvgPrice money). One task down, two to go!

To configure the ASP.NET application to support SQL Server debugging, right-click on the Project name in the Solution Explorer and choose the Property Pages from the context menu. This will bring up the dialog box shown below. Go to the Start Options tab and check the "SQL Server" checkbox in the Debuggers section. Two tasks down, one to go!

Lastly, we need to update the connection string used by the application to disable connection pooling. To accomplish this simply tack on the attribute Pooling=false to you existing connection string. Assuming the connection string information is defined within Web.config's section, you would update the connection string value like so:

All three tasks have now been completed! To test the application debugging, create an ASP.NET page that invokes the DoThings stored procedure. The demo available for download at the end of this article has such a page. When debugging the ASP.NET application and visiting this page, the breakpoint in the stored procedure is hit and control is delegated to the debugger. Once in the debugger we can step through the stored procedure's statements and view and edit the parameter values and variables through the Watch window, just like with Direct Database Debugging.

Reference:

1. http://aspnet.4guysfromrolla.com/articles/051607-1.aspx

CMKY images in browser

Today in the morning there was a mail from client that we can't see the images (JPEG) when he inserted them in the FCK editor. We did the same thing, and when we attached the file the IE, it displayed a small red cross. Again we tried to open the file in Firefox, and got the error saying the file contained errors. (Firefox is smarter !!)

We figured it out that the problem was because of the file format of the images. The images were in the CMKY format, at least not in the RGB format. After converting the images via Adobe Photoshop to RBG format, the files were perfectly opening. We spent around 3-4 hrs in all the exercise, but I learnt something which (probally) wont forget the rest of the life.

Readonly vs. const?

A const field can only be initialized at the declaration of the field. A readonly field can be initialized either at the declaration or in a constructor. Therefore, readonly fields can have different values depending on the constructor used. Also, while a const field is a compile-time constant, the readonly field can be used for runtime constants, as in the following example:

public static readonly uint l1 = (uint) DateTime.Now.Ticks;

What is exception handling?

When an exception occurs, the system searches for the nearest catch clause that can handle the exception, as determined by the run-time type of the exception. First, the current method is searched for a lexically enclosing try statement, and the associated catch clauses of the try statement are considered in order. If that fails, the method that called the current method is searched for a lexically enclosing try statement that encloses the point of the call to the current method. This search continues until a catch clause is found that can handle the current exception, by naming an exception class that is of the same class, or a base class, of the run-time type of the exception being thrown. A catch clause that doesn’t name an exception class can handle any exception. Once a matching catch clause is found, the system prepares to transfer control to the first statement of the catch clause. Before execution of the catch clause begins, the system first executes, in order, any finally clauses that were associated with try statements more nested that than the one that caught the exception. Exceptions that occur during destructor execution are worth special mention. If an exception occurs during destructor execution, and that exception is not caught, then the execution of that destructor is terminated and the destructor of the base class (if any) is called. If there is no base class (as in the case of the object type) or if there is no base class destructor, then the exception is discarded.

In the code below

int i;

i = 10;

int j = 0;

try

{

i = i++;

Response.Write(i.ToString());

j = i;

}

catch (Exception e)

{

i = 100;

}

finally

{

i = -1;

}

Response.Write(i.ToString());

After the error the control will execute the catch block and then the finally block.

In the code below:

protected void Page_Load(object sender, EventArgs e)

{

try

{

foo();

}

catch (Exception e1)

{

Response.Write(e1.Message);

}

}

private void foo()

{

int i;

i = 10;

int j = 0;

try

{

i = i++;

Response.Write(i.ToString());

j = i;

}

finally

{

i = -1;

}

Response.Write(i.ToString());

}

After the error the control will execute the finally block and then the catch block.

**********************************************************************