Tuesday, September 14, 2010

Friday, June 25, 2010

SQL optimization

Restrict the queries result set by using the WHERE clause.
This can results in good performance benefits, because SQL Server will return to client only particular rows, not all rows from the table(s). This can reduce network traffic and boost the overall performance of the query.

Restrict the queries result set by returning only the particular columns from the table, not all table's columns.
This can results in good performance benefits, because SQL Server will return to client only particular columns, not all table's columns. This can reduce network traffic and boost the overall performance of the query.

Use views and stored procedures instead of heavy-duty queries.
This can reduce network traffic, because your client will send to server only stored procedure or view name (perhaps with some parameters) instead of large heavy-duty queries text. This can be used to facilitate permission management also, because you can restrict user access to table columns they should not see.

Avoid using SQL Server cursors, whenever possible.
SQL Server cursors can result in some performance degradation in comparison with select statements. Try to use correlated subquery or derived tables, if you need to perform row-by-row operations.

Use alternative way instead of SELECT COUNT(*) statement.
Because SELECT COUNT(*) statement make a full table scan to return the total table's row count, it can take very many time for the large table. There is another way to determine the total row count in a table. You can use sysindexes system table, in this case. There is ROWS column in the sysindexes table. This column contains the total row count for each table in your database. So, you can use the following select statement instead of SELECT COUNT(*): SELECT rows FROM sysindexes WHERE id = OBJECT_ID('table_name') AND indid < 2 So, you can improve the speed of such queries in several times.

Use constraints instead of triggers, whenever possible.
Constraints are much more efficient than triggers and can boost performance. So, you should use constraints instead of triggers, whenever possible.

Use table variables instead of temporary tables.
Table variables require less locking and logging resources than temporary tables, so table variables should be used whenever possible. The table variables are available in SQL Server 2000 only.

Avoid the HAVING clause, whenever possible.
The HAVING clause is used to restrict the result set returned by the GROUP BY clause. When you use GROUP BY with the HAVING clause, the GROUP BY clause divides the rows into sets of grouped rows and aggregates their values, and then the HAVING clause eliminates undesired aggregated groups. In many cases, you can write your select statement so, that it will contain only WHERE and GROUP BY clauses without HAVING clause. This can improve the performance of your query.

Avoid using the DISTINCT clause, whenever possible.
Because using the DISTINCT clause will result in some performance degradation, you should use this clause only when it is necessary.

Include SET NOCOUNT ON statement into your stored procedures to stop the message indicating the number of rows affected by a T-SQL statement
This can reduce network traffic, because your client will not receive the message indicating the number of rows affected by a T-SQL statement.
Use the select statements with TOP keyword or the SET ROWCOUNT statement, if you need to return only the first n rows.
This can improve performance of your queries, because the smaller result set will be returned. This can also reduce the traffic between the server and the clients.

Use the FAST number_rows table hint if you need to quickly return 'number_rows' rows.
You can quickly get the n rows and can work with them, when the query continues execution and produces its full result set.

Use UNION ALL statement instead of UNION, whenever possible.
The UNION ALL statement is much faster than UNION, because UNION ALL statement does not look for duplicate rows, and UNION statement does look for duplicate rows, whether or not they exist.

Do not use optimizer hints in your queries.
Because SQL Server query optimizer is very clever, it is very unlikely that you can optimize your query by using optimizer hints, more often, this will hurt performance.

Thursday, June 10, 2010

Microsoft Pattern & Practices

http://msdn.microsoft.com/hi-in/practices/default%28en-us%29.aspx

Wednesday, June 9, 2010

Microsoft Foundation Class Library

Microsoft Foundation Class Library

The Microsoft Foundation Class (MFC) Library is a collection of class es (generalized definitions used in object-oriented programming ) that can be used in building application program s. The classes in the MFC Library are written in the C++ programming language. The MFC Library saves a programmer time by providing code that has already been written. It also provides an overall framework for developing the application program.

There are MFC Library classes for all graphical user interface elements (windows, frames, menus, tool bars, status bars, and so forth), for building interfaces to database s, for handling events such as messages from other applications, for handling keyboard and mouse input, and for creating ActiveX control s.

Wednesday, June 2, 2010

ASP.NET Authentications

Form Authentication reference:-
http://support.microsoft.com/kb/308157

Windows Authentication Reference:-
http://msdn.microsoft.com/en-us/library/ff647405.aspx

Tuesday, May 25, 2010

SDLC

see this article to know more about SDLC.

http://en.wikipedia.org/wiki/Software_development_process

http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle

Tuesday, May 11, 2010

HTTP Handlers and HTTP Modules in ASP.NET

http://www.15seconds.com/issue/020417.htm

http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=392

http://www.aspnettutorials.com/tutorials/advanced/httphandler-aspnet2-csharp.aspx

Sunday, May 9, 2010

SSRS tutorials

http://www.accelebrate.com/sql_training/ssrs_2008_tutorial.htm

Thursday, April 1, 2010

Select, Insert, Update and Delete using SqlDataAdapter

We can do the select, insert, update and delete to dataset by using SqlDataAdapter. See the following code to do that:-

SqlConnection con = new SqlConnection("Data Source=.;Initial Catalog=master;uid=sa;pwd=sql;");

SqlDataAdapter adapter = new SqlDataAdapter("select * from Customer", con);

DataSet ds = new DataSet();
//fill the dataset
adapter.Fill(ds, "emp");

//CREATE select command and build with adapter

SqlCommand cmdSelect = new SqlCommand("select * from Customer", con);
adapter.SelectCommand = cmdSelect;

//CREATE the insert command and build with adapter

SqlCommand cmdInsert = new SqlCommand("insert into emp (cusotmerName, location) values(@customerName, @location)", con);
cmdInsert.Parameters.AddWithValue("@customerName", "SENTHILNATHAN");
cmdInsert.Parameters.AddWithValue("@location", "CHENNAI");
adapter.InsertCommand = cmdInsert;

//Create update command and build with adapter

SqlCommand cmdUpdate = new SqlCommand("update emp set cusotmerName=@customerName, location=@location where CustomerNo=@CustomerNo", con);
cmdUpdate.Parameters.AddWithValue("@customerName", "SENTHILNATHAN");
cmdUpdate.Parameters.AddWithValue("@location", "CHENNAI");
cmdUpdate.Parameters.AddWithValue("@CustomerNo", "100");
adapter.UpdateCommand = cmdUpdate;

//build delete command and build with adapter

SqlCommand cmdDelete = new SqlCommand("delete from emp where CustomerNo=@CustomerNo", con);
cmdDelete.Parameters.AddWithValue("@CustomerNo", 104);
adapter.DeleteCommand = cmdDelete;

//now update the data adapter with dataset.

adapter.Update(ds, "emp");




-----------------------------------------------------------------------------

Wednesday, March 31, 2010

SqlBulkCopy

SqlBulkCopy used to store the data from one data source to another data source efficiently. See the following article, it will explain SqlBulkCopy with neat manner.

Click here to see the article

Monday, March 29, 2010

What is Design Patterns?

Design pattern is a description or template for how to solve a problem.
A design pattern is a general repeatable solution to a commonly occurring problem in software design.
A design pattern isn't a finished design that can be transformed directly into code.


http://sourcemaking.com

Tuesday, March 16, 2010

SCOPE_IDENTITY() SQL SERVER

Returns the last identity value inserted into an identity column in the same scope. A scope is a module: a stored procedure, trigger, function, or batch. Therefore, two statements are in the same scope if they are in the same stored procedure, function, or batch.

SCOPE_IDENTITY, IDENT_CURRENT, and @@IDENTITY are similar functions because they return values that are inserted into identity columns.

IDENT_CURRENT is not limited by scope and session; it is limited to a specified table. IDENT_CURRENT returns the value generated for a specific table in any session and any scope.

SCOPE_IDENTITY and @@IDENTITY return the last identity values that are generated in any table in the current session. However, SCOPE_IDENTITY returns values inserted only within the current scope; @@IDENTITY is not limited to a specific scope.

For example, there are two tables, T1 and T2, and an INSERT trigger is defined on T1. When a row is inserted to T1, the trigger fires and inserts a row in T2. This scenario illustrates two scopes: the insert on T1, and the insert on T2 by the trigger.

Assuming that both T1 and T2 have identity columns, @@IDENTITY and SCOPE_IDENTITY will return different values at the end of an INSERT statement on T1. @@IDENTITY will return the last identity column value inserted across any scope in the current session. This is the value inserted in T2. SCOPE_IDENTITY() will return the IDENTITY value inserted in T1. This was the last insert that occurred in the same scope. The SCOPE_IDENTITY() function will return the null value if the function is invoked before any INSERT statements into an identity column occur in the scope.

Failed statements and transactions can change the current identity for a table and create gaps in the identity column values. The identity value is never rolled back even though the transaction that tried to insert the value into the table is not committed. For example, if an INSERT statement fails because of an IGNORE_DUP_KEY violation, the current identity value for the table is still incremented.

OUTPUT parameters Sql server stored procedure

http://www.programmingado.net/a-145/Retrieving-SQL-Server-stored-procedure-output-parameters.aspx

Monday, March 15, 2010

appDomain

http://www.dotnetspider.com/forum/244371-AppDomain.aspx

Sunday, March 7, 2010

SQL Server-references

http://www.sqlusa.com

http://www.techonthenet.com/oracle/index.php

Monday, March 1, 2010

Design Patterns

http://www.dotnetuncle.com/Design-Patterns/dot-net-design-pattern-interview-questions.aspx


http://www.dofactory.com/Default.aspx

Web.Config Clarified

Applications of XML have been integrated into .NET to such an extent that XML is hardly a buzzword anymore. Microsoft, as you probably know, has taken XML into the core of its .NET framework. Not only is XML a generally accepted format for the exchange of data, it's also used to store configuration settings.

Configuration settings for any of your ASP.NET Web applications can be stored in a simple text file. Presented in an easily understandable XML format, this file, called Web.config, can contain application-wide data such as database connection strings, custom error messages, and culture settings.

Because the Web.config is an XML file, it can consist of any valid XML tags, but the root element should always be . Nested within this tag you can include various other tags to describe your settings. Since a Web.config file comes as a standard when you start to build a new Web application, let's look at the default XML file generated by Visual Studio .NET:




defaultLanguage="c#"
debug="true"
/>
mode="RemoteOnly"
/>




enabled="false"
requestLimit="10"
pageOutput="false"
traceMode="SortByTime"
localOnly="true"
/>
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false"
timeout="20"
/>
requestEncoding="utf-8"
responseEncoding="utf-8"
/>





Experienced ASP.NET programmers will have noticed that I've left out the comment tags that are generated automatically with the file. I've done that to provide a clear view of the XML that's used here. Also, I'll elaborate on each configuration tag later in this article, and this discussion will make the comment tags rather obsolete.

If you look at the example XML, you'll notice that the tag has only one child tag, which we call section group, the tag. A section group typically contains the setting sections, such as: compilation, customErrors, authentication, authorization, etc. The way this works is pretty straightforward: you simply include your settings in the appropriate setting sections. If, for example, you wanted to use a different authentication mode for your Web application, you'd change that setting in the authentication section.

Apart from the standard system.web settings, you can define your own specific application settings, such as a database connection string, using the tag. Consequently, your most common Web.config outline would be:










Let's discuss the details of both section groups now.
The system.web Section Group

In this section group, you'll typically include configuration settings that, in the pre-.NET era, you'd have set up somewhere in the IIS administration console. At Microsoft's MSDN Library, you can find an overview of all the tags that the system.web section group understands, but, depending on the complexity of your site, you may not ever use even half of those options.

Let's have a look at the most valuable tweaks you can make within the system.web section group, in alphabetical order.



The authentication section controls the type of authentication used within your Web application, as contained in the attribute mode. You'll enter the value "None" if anyone may access your application. If authentication is required, you'll use "Windows", "Forms" or "Passport" to define the type of authentication. For example:





To allow or deny access to your web application to certain users or roles, use or child tags.






It's important to understand that ASP.NET's authorization module iterates through the sections, applying the first rule that corresponds to the current user. In this example, users carrying the role Administrators or Users will be allowed access, while all others (indicated by the * wildcard) will encounter the second rule and will subsequently be denied access.



Here, you can configure the compiler settings for ASP.NET. You can use loads of attributes here, of which the most common are debug and defaultLanguage. Set debug to "true" only if you want the browser to display debugging information. Since turning on this option reduces performance, you'd normally want to set it to "false". The defaultLanguage attribute tells ASP.NET which language compiler to use, since you could use either Visual Basic .NET or C# for instance. It has value vb by default.


verio.com

To provide your end users with custom, user-friendly error messages, you can set the mode attribute of this section to On. If you set it to RemoteOnly, custom errors will be shown only to remote clients, while local host users will see the ugly but useful ASP.NET errors -- clearly, this is helpful when debugging. Setting the mode attribute to Off will show ASP.NET errors to all users.

If you supply a relative (for instance, /error404.html) or absolute address (http://yourdomain.com/error404.html) in the defaultRedirect attribute, the application will be automatically redirected to this address in case of an error. Note that the relative address is relative to the location of the Web.config file, not the page in which the error takes place. In addition you can use tags to provide a statusCode and a redirect attribute:








The globalization section is useful when you want to change the encoding or the culture of your application. Globalization is such an extensive subject that an entire article could be dedicated to the matter. In short, this section allows you to define which character set the server should use to send data to the client (for instance UTF-8, which is the default), and which settings the server should use to interpret and displaying culturally specific strings, such as numbers and dates.

culture="nl-NL" />

Encoding is done through the attributes requestEncoding and responseEncoding. The values should be equal in all one-server environments. In this example, the application culture is set to Dutch. If you don't supply a culture, the application will use the server's regional settings.



You can use the httpRuntime section to configure a number of general runtime settings, two of which are particularly convenient.



The first attribute specifies the number of requests the server may queue in memory at heavy-traffic times. In the example, if there are already 100 requests waiting to be processed, the next request will result in a 503 error ("Server too busy").

The executionTimeout attribute indicates the number of seconds for which ASP.NET may process a request before it's timed out.



In this section of the Web.config file, we tell ASP.NET where to store the session state. The default is in the process self:



Session variables are very powerful, but they have a few downsides. Information is lost when the ASP.NET process crashes, and sessions are generally useless in the case of a Web farm (multiple Web servers). In that instance, a shared session server can solve your issues. It's beyond the scope of this article to expand on this topic, but it's worth a mention. More information on sessionState can be found in the MSDN Library online.



Your application's trace log is located in the application root folder, under the name trace.axd. You can change the display of tracing information in the trace section.

The attributes you will look for initially are enabled: localOnly, and pageOutput.



Set localOnly to "false" to access the trace log from any client. If you set the value of pageOutput to "true", tracing information will be added to the bottom of each Web page.
The appSettings Section Group

Apart from the Website configuration settings I've been talking about in the preceding paragraphs, you'll know that a programmer frequently likes to use custom application-wide constants to store information over multiple pages. The most appealing example of such a custom constant is a database connection string, but you can probably think of dozens more from your own experience.

The common denominator of these constants is that you want to retrieve their values programmatically from your code. The Web.config file provides the possibility to do so, but as a security measure, these constants have to be included in the section group. Just like , is a direct child tag of the Web.config's configuration root.

A typical custom section group would look something like this:






The example shows that keys and values can be included in the custom application settings via an tag. The way to access such a value in any of your Web pages is illustrated below:

ConfigurationSettings.AppSettings("sqlConn")

Yes, it's as easy as that! Note that the value of these settings is always a String format.
A Few Other Issues

I won't go into them here, but the Web.config file can contain several other section groups besides the aforementioned system.web and appSettings, such as the configSettings group.

* A Web application can contain more than one Web.config file. The settings in a file apply to the directory in which it's located, and all child directories. Web.config files in child directories take precedence over the settings that are specified in parent directories.
* Web.config files are protected by IIS, so clients cannot get to them. If you try to retrieve an existing http://mydomain.com/Web.config file, you'll be presented with an "Access denied" error message.
* IIS monitors the Web.config files for changes and caches the contents for performance reasons. There's no need to restart the Web server after you modify a Web.config file.

Closing Remarks

In this article, I've touched upon the possibilities that the Web.config file offers the ASP.NET programmer. You can use the easily accessible XML file to define your application settings, without the hassle of using the IIS management console. With the Web.config file, ASP.NET lets you add, change and delete basic configuration settings like authentication and authorization, custom error displaying, and tracing in a straightforward manner.

Moreover, the Web.config file offers you room to define any custom key you require, such as database connection strings. What we've subsequently seen is that, with just one line of code, you can retrieve the information you need from any page in your application.

Multilingual in .NET

http://www.c-sharpcorner.com/UploadFile/pradeepkv/MultilingualAppsInNet11282005010748AM/MultilingualAppsInNet.aspx

Sunday, February 28, 2010

Multithreading

What Is Multithreading?

Multithreading is a technique that can be used to perform time consuming tasks in a separate additional thread other than the main application thread.

When you, for example, have a time-consuming function, you may need to call this function as a response of a button click. Now, instead of freezing all your application waiting for this function to return / to finish, you can create a new thread and assign this function to. When you do this, your application interface will not be blocked and you can use it to perform other tasks. At the same time, your time-consuming task is being carried out in the background.

You can think of it as the two threads: the main one, and the newly created one. Both are running in parallel, and this improves the performance and responsiveness of your application.
Advantages and Disadvantages of Using Multithreading

Despite improving your application's performance, and avoiding unresponsive user interface, multithreading has the following disadvantages:

* There is a runtime overhead associated with creating and destroying threads. When your application creates and destroys threads frequently, this overhead affects the overall application performance.
* Having too many threads running at the same time decreases the performance of your entire system. This is because your system is attempting to give each thread a time slot to operate inside.
* You should design your application well when you are going to use multithreading, or otherwise your application will be difficult to maintain and extend.
* You should be careful when you implement a multithreading application, because threading bugs are difficult to debug and resolve.

Notes:

* Each time a thread is created, a certain amount of memory is consumed to hold this thread context information. Hence, the number of threads that can be created is limited by the amount of available memory.
* More threads does not mean a faster responsive application, instead it can decrease the performance of your application.

The Thread Pool

Instead of creating a thread each time we need one, and then destroying it after finishing, the .NET framework introduces the concept of thread pool. In the thread pool technique, and instead of creating a new thread whenever you need one, your application will obtain a thread from the thread pool. After that obtained thread completes its task, it will be returned to the thread pool instead of destroying it - waiting for the next acquiring. This reusability increases the overall application performance, and reduces the cost of excessive thread creation and termination.

To make use of this technique, you need to use the System.Threading.ThreadPool class. The thread pool will be created the first time you use it. The number of total threads in this pool is restricted by default to 25 threads. This means that all of these 25 threads may be busy at some point. If you need to acquire a new thread at this point, your task will be scheduled waiting for a thread to finish its task and return to the pool.

Wednesday, February 24, 2010

4 - Tier Architecture

See the 3-tier architecture in Microsoft


1. Business Object [BO]
2. Business Access Layer [BAL]
3. Data Access Layer [DAL]
4. Presentation Layer


Business Object(BO)
class employee.cs
{
int employeeID= 0;
string m_FirstName = string.Empty;
string m_LastName = string.Empty;
int salary= 0;

#region Propertiers
public int employeeID
{
get { return employeeID; }
set { employeeID = value; }
}
public string FirstName
{
get { return m_FirstName; }
set { m_FirstName = value; }
}
public string LastName
{
get { return m_LastName; }
set { m_LastName = value; }
}
public int Salary
{
get { return salary; }
set { salary = value; }
}
#endregion Properties
2. Business Access Layer [BAL]
using System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
///
/// Summary description for PersonBAL
///

public class EmployeeBAL

{
public EmployeeBAL()
{
}
///
/// insert records into database
///

///
///

public int Insert(Employee employee)
{
EmployeeDAL eDAL = new EmployeeDAL();
try
{
return eDAL.Insert(person);
}
catch
{
throw;
}
}
///
/// Update records into database
///

///
///
public int Update(Employee employee)
{
EmployeeDAL eDAL = new EmployeeDAL();
try
{
return eDAL.Update(person);
}
catch
{
throw;
}
}
///
/// Load records from database
///

///
public DataTable Load()
{
EmployeeDAL eDAL = new employeeDAL();
try
{
return eDAL.Load();
}
catch
{
throw;
}
finally
{
eDAL = null;
}
}
///
/// Delete record from database
///

///
///
public int Delete(Person person)
{
EmployeeDAL eDAL = new EmployeeDAL();
try
{
return eDAL.Delete(person);
}
catch
{
throw;
}
finally
{
eDAL = null;
}
}
}

3. Data Access Layer [DAL]

this is also contains in App_Code folder and contains all the code to access database.

4. Presentation Layer
This Layer contains the UI.



See the 3-tier architecture in Microsoft

Thursday, February 18, 2010

Tips on how to avoid deadlocking on your SQL Serve

# Ensure the database design is properly normalized.
# Have the application access server objects in the same order each time.
# During transactions, don't allow any user input. Collect it before the transaction begins.
# Avoid cursors.
# Keep transactions as short as possible. One way to help accomplish this is to reduce the number of round trips between your application and SQL Server by using stored procedures or keeping transactions with a single batch. Another way of reducing the time a transaction takes to complete is to make sure you are not performing the same reads over and over again. If your application does need to read the same data more than once, cache it by storing it in a variable or an array, and then re-reading it from there, not from SQL Server.
# Reduce lock time. Try to develop your application so that it grabs locks at the latest possible time, and then releases them at the very earliest time.
# If appropriate, reduce lock escalation by using the ROWLOCK or PAGLOCK.
# Consider using the NOLOCK hint to prevent locking if the data being locked is not modified often.
# If appropriate, use as low of an isolation level as possible for the user connection running the transaction.
# Consider using bound connections.

Wednesday, February 17, 2010

Relation Between Application Domains and Assemblies

Most development and runtime environments has a definition for the building blocks of an application. Assemblies are the building blocks of .NET framework applications. They are the fundamental unite of deployment. An assembly consists of types and resources working together to form a logical unit of the functionality of your application. You can divide your .NET application into assemblies. The assembly file can have an .EXE or a .DLL extension.

As we mentioned previously, you can run more than one application domain within your application. Each application domain will run a given piece of code. An assembly is simply the piece of code we mean here. So, each application domain can run an assembly within the entire application. This is the relation between application domains and assemblies.

AppDomain and .Net Developer

You’ve created two ASP.NET applications on the same server, and have not done any special configuration. What is happening?

A single ASP.NET worker process will host both of the ASP.NET applications. On Windows XP and Windows 2000 this process is named aspnet_wp.exe, and the process runs under the security context of the local ASPNET account. On Windows 2003 the worker process has the name w3wp.exe and runs under the NETWORK SERVICE account by default.

An object lives in one AppDomain. Each ASP.NET application will have it’s own set of global variables: Cache, Application, and Session objects are not shared. Even though the code for both of the applications resides inside the same process, the unit of isolation is the .NET AppDomain. If there are classes with shared or static members, and those classes exist in both applications, each AppDomain will have it’s own copy of the static fields – the data is not shared. The code and data for each application is safely isolated and inside of a boundary provided by the AppDomain

In order to communicate or pass objects between AppDomains, you’ll need to look at techniques in .NET for communication across boundaries, such as .NET remoting or web services.

Note again: the one caveat to the idea of an AppDomain as a boundary is that ASP.NET applications will run with full trust by default. Fully trusted code can execute native code, and native code can essentially have access to anything inside the process. You’ll need to run applications with partial trust to restrict access to unmanged code and verify all managed code to secure AppDomains.

Advantages of .NET AppDomain

You may ask, why should I create more than one application domain within my application?

The following advantages of application domains answer this question.

* In terms of isolation, code running in one application domain can not access code or resources running in another application domain.
* In terms of security, you can run more than one set of web controls in a single browser process. Each set of them is running in a separate application domain so each one can not access the data or resources of the other sets. You can control the permissions granted to a given piece of code by controlling the application domain inside which the code is running.
* In terms of robustness, fault in code running in one application domain can not affect other applications although they all are running inside the same process. Individual application domain can be stopped without stopping the entire process, you can simply unload the code running in a single application domain.

So, from the above advantages, you can observe that by using application domains you can create rather robust .NET applications. It increases isolation, stability, and security of your application.

Application Domain or AppDomain

.NET introduces the concept of an application domain, or AppDomain. Like a process, the AppDomain is both a container and a boundary. The .NET runtime uses an AppDomain as a container for code and data, just like the operating system uses a process as a container for code and data. As the operating system uses a process to isolate misbehaving code, the .NET runtime uses an AppDomain to isolate code inside of a secure boundary.

Note, however, that the application domain is not a secure boundary when the application runs with full trust. Applications running with full trust can execute native code and circumvent all security checks by the .NET runtime. ASP.NET applications run with full trust by default.

An AppDomain belongs to only a single process, but single process can hold multiple AppDomains. An AppDomain is relatively cheap to create (compared to a process), and has relatively less overhead to maintain than a process. For these reasons, an AppDomain is a great solution for the ISP who is hosting hundreds of applications. Each application can exist inside an isolated AppDomain, and many of these AppDomains can exist inside of a single process – a cost savings.

Friday, February 12, 2010

Top 10 Mistakes on SQL SERVER

10. Unknown Scalability Requirements

9. Improperly Normalized Tables

8. Improper Indexing

7. No Baseline or Benchmarks

6. Disks — Thinking about Space but Not I/O

5. Lack of Error Notification

4. Poor or Nonexistent Backup Strategy

3. Lack of Query Tuning and Optimization

2. Ignorance of Internals

1. Overuse of Cursors


Benefits of Stored Procedures

Modular programming :
You can write a stored procedure once, then call it from multiple places in your application.

Performance

Stored procedures provide faster code execution and reduce network traffic.

* Faster execution: Stored procedures are parsed and optimized as soon as they are created and the stored procedure is stored in memory. This means that it will execute a lot faster than sending many lines of SQL code from your application to the SQL Server. Doing that requires SQL Server to compile and optimze your SQL code every time it runs.
* Reduced network traffic: If you send many lines of SQL code over the network to your SQL Server, this will impact on network performance. This is especially true if you have hundreds of lines of SQL code and/or you have lots of activity on your application. Running the code on the SQL Server (as a stored procedure) eliminates the need to send this code over the network. The only network traffic will be the parameters supplied and the results of any query.

Security

Users can execute a stored procedure without needing to execute any of the statements directly. Therefore, a stored procedure can provide advanced database functionality for users who wouldn't normally have access to these tasks, but this functionality is made available in a tightly controlled way.

Thursday, January 28, 2010

Multicast Delegates C# an Example

The C# language has a feature known as the multicast delegate. Any delegate that has a void return type, is a multicast delegate. A multicast delegate can be assigned and invoke multiple methods.

You may have seen hints of this in your code. For example, if you are doing ASP.NET development and have ever looked at a page's InitializeComponent() method, you may have noticed a statement like this:

this.SearchButton.Click += new System.EventHandler(this.SearchButton_Click);

Notice the += in that statement. That is a clue. You could add another event handler if you wanted, and it would get called as well. For example, let's say you wanted to also call a method named NotifyStatistics every time the Search button was clicked. Then your code could be:

this.SearchButton.Click += new System.EventHandler(this.SearchButton_Click);
this.SearchButton.Click += new System.EventHandler(this.NotifyStatistics);

Every time the user clicks the Search button, first SearchButton_Click() is called, followed by NotifyStatistics(). The event handlers are called in the order they are added. Likewise, using -=, an event handler can be removed.