Saturday, 21 June 2008

Array

Que:- Can you store multiple data types in System.Array?

Ans:- No.


Que:- What�s the difference between the System.Array.CopyTo() and System.Array.Clone()?

Ans:- The first one performs a deep copy of the array, the second one is shallow.

Thursday, 17 January 2008

Differences between Server-side and Client-side code?

Server side code executes on the server. For this to occur page has to be submitted or posted back. Events fired by the controls are executed on the server. Client side code executes in the browser of the client without submitting the page.
e.g. In ASP.NET for web controls like asp: button the click event of the button is executed on the server hence the event handler for the same in a part of the code-behind (server-side code). Along the server-side code events one can also attach client side events which are executed in the client�s browser i.e. javascript events.

Object Oriented Programming

 Click Here to View Latest ASP.Net Questions

 OOP Features

� Encapsulation � Objects are by nature, encapsulated. That is, only certain portions of their fields and methods are publicly accessible from other classes and one doesn�t really need to know the inner workings of an object in order to use it. Encapsulation has certain benefits. By hiding the inner workings of a class, it makes that class simpler to use because the developer only sees and has access to what is necessary to use the class. Furthermore, the developer cannot accidentally override the data inside that class.

� Inheritance � Often considered the "Holy Grail" of programming inheritance is just as often misused or misunderstood. Inheritance defines a particular ability of classes to inherit the data members and functionality from other more generalized classes. The new or "child" class can than add more specific functionality that is parent does not possess.

� Polymorphism � Polymorphism is even more difficult to understand and explain. Literally meaning "many forms" polymorphism is the ability for related classes to have the methods or functions with the same name and syntax but different implementations.

� Aggregation/Composition � Although these two terms are often used interchangeably, aggregation is more generalized term referring to groups of objects being used to make up another object, much the way a car is made of various parts. Composition is a much more specific form of aggregation where one the pieces can only belong to one whole and outside of that whole, they no longer exist. Usually though, you�ll hear people refer to composition in the more general sense that aggregation defines.

� Interfaces � Perhaps one of the most mysterious features of OOP languages, interfaces have very specific purposes, especially in component development. Classes that inherit interfaces are required to have certain methods, fields and/or properties defined and implemented. This allows related classes to have a consistent manner of using them. For example, all the .NET collection classes inherit from the IEnumerator interface, forcing them to have the methods MoveNext(), Reset() and Current property.

Transactions

Transactions

A transaction is a sequence of operations performed as a single logical unit of work. A logical unit of work must exhibit four properties, called the ACID (Atomicity, Consistency, Isolation, and Durability) properties, to qualify as a transaction:

Atomicity

A transaction must be an atomic unit of work; either all of its data modifications are performed, or none of them is performed.

Consistency
When completed, a transaction must leave all data in a consistent state. In a relational database, all rules must be applied to the transaction's modifications to maintain all data integrity. All internal data structures, such as B-tree indexes or doubly linked lists, must be correct at the end of the transaction.

Isolation
Modifications made by concurrent transactions must be isolated from the modifications made by any other concurrent transactions. A transaction either sees data in the state it was in before another concurrent transaction modified it, or it sees the data after the second transaction has completed, but it does not see an intermediate state. This is referred to as serializability because it results in the ability to reload the starting data and replay a series of transactions to end up with the data in the same state it was in after the original transactions were performed.

Durability
After a transaction has completed, its effects are permanently in place in the system. The modifications persist even in the event of a system failure.
Specifying and Enforcing Transactions
SQL programmers are responsible for starting and ending transactions at points that enforce the logical consistency of the data. The programmer must define the sequence of data modifications that leave the data in a consistent state relative to the organization's business rules. The programmer then includes these modification statements in a single transaction so that Microsoft� SQL Server� can enforce the physical integrity of the transaction.
It is the responsibility of an enterprise database system, such as SQL Server, to provide mechanisms ensuring the physical integrity of each transaction. SQL Server provides:
  • Locking facilities that preserve transaction isolation.
  • Logging facilities that ensure transaction durability. Even if the server hardware, operating system, or SQL Server itself fails, SQL Server uses the transaction logs, upon restart, to automatically roll back any uncompleted transactions to the point of the system failure.
  • Transaction management features that enforce transaction atomicity and consistency. After a transaction has started, it must be successfully completed, or SQL Server undoes all of the data modifications made since the transaction started.

Transaction is a procedure the data tranmitted into the database either sucess of  failure sate.

It has 2 objects

COMMIT

ROLLBACK


    

Strong Naming

The Secrets of Strong Naming
The strength of a strong name lies in the protection that it offers your assemblies. The .NET Framework uses strong names to identify assemblies and to protect them from tampering.

Hashes and Signing

To grasp the way that strong names work, you first need to understand a pair of cryptographic concepts: hashing and digital signatures.
Hashing is used to create a unique, compact value for a plaintext message. "Message" is a very broad term here; in terms of assemblies, the message is the assembly itself. The message is used as an input to the hash algorithm (in the case of strong naming, the SHA1 algorithm is used). Figure 1 diagrams the process.
<!--[if !vml]-->How hashing works<!--[endif]-->

Hashing is a one-way street: you can't decrypt the hash value once it has been computed. However, hashing is very useful for comparing values. If two assemblies produce the same hash value, you can assume that the assemblies are the same. Conversely, if hashing an assembly produces a value that doesn't match a previously-calculated hash, you know that something in the assembly has been changed.
Knowing the hash value for an assembly lets you check that no one has tampered with the assembly. But how do you prevent someone from tampering with the hash value? That's where digital signing comes in. While the mathematics of digital signatures are complex, the concept is fairly simple. A digital signature depends on a pair of related numbers, the public key and the private key. When data is encrypted with the public key, it can only be decrypted with the private key (and vice versa), as shown in Figure 2.
<!--[if !vml]-->Using key pairs<!--[endif]-->





Strong Naming for Assembly Identity
The combination of hashing and digital signing allows .NET to protect your assemblies from tampering. Here's how it works. First, a hash value is created from the assembly. Then, the hash value is encrypted with your private key and placed, along with your public key, in the assembly itself. Figure 3 shows this process schematically.
<!--[if !vml]-->Placing a strong name in an assembly<!--[endif]-->
The CLR validates assemblies at runtime by comparing two sets of hash values. First, the public key is used to decrypt the encoded version of the hash. Second, a new hash is computed from the current contents of the assembly. If the two hashes match, all is well. Figure 4 shows this process.
<!--[if !vml]-->Checking the strong name in an assembly<!--[endif]-->
What happens if an assembly has been tampered with after it was signed? In this case, the new hash value calculated at runtime won't match the stored hash value that was encrypted with your private key. Under those circumstances, the CLR will refuse to load the assembly.
Note that the strong name guarantees the integrity of the assembly, not necessarily its safety! There's nothing to prevent someone from creating a malicious assembly and signing it with a strong name.
You can use a strong name to verify that an assembly came from a particular source, and that it wasn't tampered with after it was signed. It's up to you to decide, based on whatever information you choose, whether to trust code from that source.

What's in a (Strong) Name?

In addition to a hash derived from the assembly's contents, the strong name includes three other pieces of information:
  • The simple text name of the assembly
  • The version number of the assembly
  • The culture code (if any) of the assembly
This entire information works together to supply a unique identity for each assembly. The CLR uses this information when deciding whether a particular assembly is the one called for by a reference from another assembly. When you set a reference from one assembly to another, the calling assembly stores a representation of the called assembly's public key. At runtime, the CLR can use this to check that the referenced assembly comes from the correct vendor. In addition, the other information in the strong name is used to determine whether a particular assembly fills the binding policy requirements for the reference.
The Mechanics of Strong Naming
Both the .NET Framework SDK and Visual Studio .NET provide tools for assigning strong names. That makes sense, because using Visual Studio .NET to create assemblies is completely optional. Before you can sign anything, you need to create a key pair (consisting of a public key and a private key). Typically, you'll store your key pair in a file with the extension .snk. To do this, you use the strong name tool, sn.exe:
sn -k MyKeyFile.snk
If you're using the command-line compilers (vbc.exe or csc.exe), you can specify the key pair to use in your command line to the assembly linker, al.exe. For example, you might sign MyFile.dll with the key pair in MyKeyFile.snk with this command line:
al /out:MyFile.dll MyFile.netmodule /keyfile:MyKeyFile.snk
If you're using Visual Studio .NET, you'll still generate your key pair at the command line. After generating it, you can include it in your assembly by specifying the AssemblyKeyFile attribute in the assembly information file (AssemblyInfo.vb or AssemblyInfo.cs). In a C# project, for example, you can include a key file and produce a signed assembly with this attribute:
[assembly: AssemblyKeyFile ("..\\..\\MyKeyFile.snk")]
The filename in the AssemblyKeyFile attribute should include the full relative path from the compiled assembly to the key file.

Keeping Secrets with Delay Signing

Protecting your private key is obviously very important; if a nefarious person gets your private key, they can produce assemblies that appear to have been signed by you. Because of this, you may wish to keep your private key a closely-guarded secret, known only to a few people in the company. But then, how can you handle assembly signing? It would be tedious if you were the only person who knew the private key, and you had to sign every build of every assembly produced by every developer in your company.
Fortunately, .NET provides a way around this problem: delay signing. With delay signing, you can build and test an assembly knowing only the public key. The private key can be applied later if the assembly is actually shipped to customers. Here is a summary of the delay signing process:
  1. Extract the public key from the public/private key pair. To extract the public key from a file that is storing the public/private key pair, you can use the strong name tool with a slightly different command line:

    sn.exe -p MyKeyFile.snk MyPublicKeyFile.snk
    <!--[if !supportLineBreakNewLine]-->
    <!--[endif]-->
  2. Distribute the file containing only the public key to all of the developers in the company, and store the file containing both keys securely.
    <!--[if !supportLineBreakNewLine]-->
    <!--[endif]-->
  3. Include the public key file in your assembly information file, and specify delay signing:

    [assembly: AssemblyDelaySign(true)]

    [assembly: AssemblyKeyFile("..\\..\\MyPublicKeyFile.snk")]
    <!--[if !supportLineBreakNewLine]-->
    <!--[endif]-->
If you're using the assembly linker tool rather than Visual Studio .NET, use the /delaysign command-line switch to indicate delay signing.





<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->
  1. Turn off verification for the assembly if you're storing the assembly in the GAC. By default, the GAC verifies the strong name of each assembly. If the assembly is not signed by using the private key, this verification fails. So, for development and testing purposes, you can relax this verification for an assembly by issuing the following command:

    sn.exe -Vr MyFile.dll
    <!--[if !supportLineBreakNewLine]-->
    <!--[endif]-->
  2. At this point, you can use the assembly freely in testing and development.
    <!--[if !supportLineBreakNewLine]-->
    <!--[endif]-->
  3. When you're ready to deploy a delay-signed assembly, you need to sign it with your private key:

    sn.exe -R MyFile.dll MyKeyFile.snk
    <!--[if !supportLineBreakNewLine]-->
    <!--[endif]-->
  4. Finally, you can instruct the GAC to resume verification for an assembly by issuing the following command:

    sn.exe -Vu MyFile.dll

Explian Trigger

A trigger is a database object that is bound to a table. It is a special type of stored procedure that executes automatically when any DML operations are performed.
Microsoft SQL Server 2000 supports two different types of triggers namely INSTEAD OF and AFTER Trigger. Both this trigger is different in the execution.
It supports Multiple after Trigger also. Triggers cannot be created on the temporary tables.
After Trigger
After trigger automatically get executed before the transaction get completed or rollback. After trigger created only on tables not in views. This is very useful to maintain the data integrity between the tables.

EXAMPLE

CREATE TRIGGER after trigger
ON department
FOR INSERT AS
Print ('After Tigger is initiated')
GO
BEGIN TRANSACTION
DECLARE @ERR INT
INSERT INTO department(USERNAME, PASSWORD)VALUES('Ram','india')
SET @ERR = @@Error
IF @ERR = 0
BEGIN
COMMIT TRANSACTION
PRINT 'COMMIT TRANSACTION'
END
ELSE
BEGIN
ROLLBACK TRANSACTION
PRINT 'ROLLBACK TRANSACTION'
END--End of the program


INSTEAD OF Triggers
This trigger gets executed automatically before the primary key and the foreign key column constraint are checked. Whereas the traditional trigger (After Trigger) get executes automatically after all the check constraints are checked.
Triggers are a powerful tool that can be used to enforce the business integrity or data integrity automatically when the data is modified. Triggers should be used to maintain the data integrity only if you are not capable to enforce the data integrity using CONSTRAINTS, RULES.


2) To check whether the given column present in the table if present display the tables which contains this columns in the database
set ANSI_NULLS ON
set QUOTED_IDENTIFIER ON
GO
ALTER procedure [dbo].[sp_Search_Columns](
@column varchar(500)
)
as
Begin
set nocount on
declare @tname varchar(500),
@intNum int
--Create a temporary table to store the table having the columns
create table #Tables1(TableNames varchar(500))
Declare TableNames cursor for
--select all the tables from the database
Select Table_name from INFORMATION_SCHEMA.Tables order by TABLE_NAME
--verify for each table in the database whether the coloumn present or not
open TableNames fetch next from TableNames into @tname
while @@FETCH_STATUS=0
begin
--Check if the table contains the coloumn.
--if the coloumn is present in the
select @intNum=count(*) from information_schema.columns where table_name = @tname and column_name=@column
if(@intNum > 0)
--if the table contains the column then insert that table name in the temp table for further display
insert into #Tables1 values(@tname)
--point the pointer to check for the next table
fetch next from TableNames into @tname
End
close TableNames
--deallocate the curser
deallocate TableNames
--select all the tables which contains the column
select * from #Tables1
end
Out Put of the query :
EXEC sp_Search_Columns 'FirstName'
Tablenames
Account
COBInfo
COBInfo_backup
COBInfoHistory
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

3) How to find the number of days in a month
Create Function NumDaysInMonth (@dtDate datetime) returns intasBeginReturn(Select Day(DateAdd(Month, 1, @dtDate) - Day(DateAdd(Month, 1, @dtDate))))EndGo

MVC (Model View Controller) For ASP.NET

MVC (Model View Controller) For ASP.NET
Historical Background
For those unfamiliar with MVC, MVC stands for Model, View, Controller. The Model is the representation of the thing the user is trying to interact with. It typically holds the data and business rules.
The View pulls information from the Model and renders that information in a way the user will understand.
The Controller interprets actions by the user, usually mouse and keyboard events, and sends the information to the model or the view.
The model knows nothing about the view or the controller other than that they exist. The view and the controller know as much as possible about the model.
The advantage to this type of architecture is that the view and the controller may be changed without affecting the model. For web applications that need to render themselves on various browsers and devices this is an ideal architecture that allows the application to be written originally for a desktop browser and later written for a PDA by changing only the view layer.
<!--[if !vml]-->mvc.gif<!--[endif]-->
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

Typical UML of MVC
JSP's Model II architecture is an attempt by those working in this environment to coerce MVC into a web based world. In this case the controller can no longer access the view directly, so we end up with the controller sending information to the model and the view always pulling the information out of the model.
<!--[if !vml]-->webmvc.gif<!--[endif]-->
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->
UML of MVC on the web
In a Model 2 architecture, a central controller is used which then delegates to other controllers and/or the appropriate resulting view. In terms of physical components of a JSP environment, MVC is typically implemented by posting to a servlet that processes the form information and then forwards to a JSP page to render the resulting page.
This combined with EJB or JavaBeans keeps the view separate from the controller and the model.
<!--[if !vml]-->jspmvc.gif<!--[endif]-->
This translates rather easily to ASP. The Servlet becomes an ISAPI.DLL, the JSP page becomes an ASP page, and the model becomes ActiveX controls.
<!--[if !vml]-->aspmvc.gif<!--[endif]-->
Enter ASP.NET
If your only experience with MVC is through Model 2 architecture, the ability to implement MVC architecture in ASP.NET is not immediately apparent. However, ASP.NET not only allows MVC, it encourages it in the way the pattern was originally conceived.
Since the definition of MVC states that the View renders the data from the Model and that the Controller sends user events to the Model, generally from the elements rendered on the view, most could agree that there is a very high natural coupling between the View and the Controller. So, a natural real world implementation of MVC, and indeed what you normally find outside of web applications, is a one to one correspondence between the View and the Controller. However, in a web application, there is a need to not only send data to the model, there is also a need to control which view should render based on the data the model currently contains. A kind of a "View Controller." In some Model 2 implementations, there is a central Controller which we will call the "View Controller." This View Controller delegates form processing to other programming entities and eventually redirects to the appropriate view. JavaBeans in the case of JSP, ActiveX controls in the case of ASP. If you've ever worked with the Struts framework for JSP you are familiar with this model.
Since ASPX pages post back to themselves, we obviously can't use a "View Controller." So, how does one implement the same functionality in .NET? Furthermore, those familiar with Struts will recognize that the ability to loosely couple the views (or controllers) from each other is not available in ASP.NET "out of the box."
The following architecture solves both of these problems.
In a Model 2 architecture using a Central Controller, a delegate pattern is used to control access to the different services, or sub-controllers. You ask for a service and the central controller determines if you should be allowed access to the service and how to implement the service.
In ASP.NET, you generally ask for the service directly. Instead of a service being a sub-controller, it is the main point of entry. What this doesn't offer is a central location for determining if you should have access to the service in the first place, or, any other common processing that should happen in all of the services. However, by having all of your code-behind pages inherit from a common class that is a subclass of System.Web.UI.Page, you can place all of this pre-processing code in the OnLoad() method that you override from the Page class. OnLoad() is call by the framework every time the page is loaded. But before the Page_Load() method is called in your code-behind page. This allows you to verify that the service is allowed and do any redirecting you need to do in one central location, using Server.Transfer(), similar to what a Central Controller would do. I named my View Controller class ViewController.
The second requirement, making the views loosely coupled from each other, requires a bit more work. First, you will need to create an enum in your ViewController class that has an entry that corresponds to each page in your web application. I also added an enum named UNDEFINED. Second, you will need to create a member variable to hold the ID of the page. I initialized mine to UNDEFINED. This gets placed in your ViewController class and is of the type of your enum. Third, you will need to create a property to access this member variable. I've named mine ServiceID. Fourth, create a method in your ViewController named getServicePage() that takes the enum as a parameter and returns a string containing the appropriate aspx file. Finally, in the constructor of each of your code-behind pages, set the ServiceID of the page. Now, anywhere in your code where you are redirecting or linking to an aspx page in your application, you will call the getServicePage() method to retrieve the name of the file to redirect to.
If you've ever refactored your website to the point of renaming web pages, you should immediately see that this will significantly simplify maintenance. If you want to rename an aspx file you now can rename the file and change the lookup in getServicePage and your site should still work. The only problem with this implementation is that there is no good way to enforce it's usage.
<!--[if !vml]-->aspxmvc.gif<!--[endif]-->

Conclusion

With the advent of ASP.NET, many of the hacks we have had in place have been removed. All of the view and controller related code is now in essentially one place instead of two. The defacto standard for writing view based application (MVC) is preserved.