Different Type of Reports in SSRS (2008)

• Ad hoc reports
• Cached reports
• Clickthrough reports
• Drilldown reports
• Drillthrough reports
• Linked reports
• Parameterized reports
• Snapshot reports
• Subreports

Implementation of two interface having the same method signature in the same class

If the signature of the methods in two different interfaces are same and both the interfaces are going be implemented in the same class. Following is the two interfaces:
public interface Interface1 { string PrintName(); }
public interface Interface2 { string PrintName(); }
From the above code we can infer that we have two interface with names Interface1 and Interface2 and both have a single method named “PrintName”. The signatures of both the methods are same and we need to implement the interfaces in our class “myClass”. One way of implementing the interface is as shown below (just having a “public” implementation of the interface method only once).
public class myClass : Interface1, Interface2
{
public myClass() { }
public string PrintName() { return this.GetType().Name; }
}
The above implementation has got a limitation i.e the method “PrintName” is considered to be a common method for all i.e common method for the class, and for the interfaces Interface1 and Interface2. If you are writing a code shown below
myClass myclass = new myClass ();
Interface1 i1 = new myClass ();
Interface2 i2 = new myClass ();
Console.WriteLine(myclass.PrintName());
Console.WriteLine(i1.PrintName());
Console.WriteLine(i2.PrintName());
All the calls to method “PrintName” will give you the same result, the name of the class i.e. “myClass”. This is because all call to the method goes to the same definition. Now if you want to give different implementation to the methods in interface Interface1 and Interface2; you have two implementations of the same method and prefix the method names with the interface name as shown below.
public class myClass : Interface1, Interface2
{
public myClass() { }
string Interface1.PrintName() { return “Interface1 PrintName Method”; }
string Interface2.PrintName() { return “Interface2 PrintName Method”; }
}
Now the below code will give you different output.
Interface1 i1 = new myClass();
Interface2 i2 = new myClass();
Console.WriteLine(i1.PrintName());// Will print " Interface1 PrintName Method"
Console.WriteLine(i2.PrintName());// Will print " Interface2 PrintName Method"
So this is how two interfaces having the same method signature can be given different implementation in the same class.

Life cycle of an object

1. When the object is created, memory is allocated for it, the constructor is run, and the object is considered live.
2. If the object, or any part of it, cannot be accessed by any possible continuation of execution, other than the running of destructors, the object is considered no longer in use and it becomes eligible for destruction.
3. The C# compiler and the garbage collector may choose to analyze code to determine which references to an object may be used in the future. For instance, if a local variable that is in scope is the only existing reference to an object, but that local variable is never referred to in any possible continuation of execution from the current execution point in the procedure, the garbage collector may (but is not required to) treat the object as no longer in use.
4. Once the object is eligible for destruction, at some unspecified later time the destructor (if any) for the object is run. Unless overridden by explicit calls, the destructor for the object is run once only.
5. Once the destructor for an object is run, if that object, or any part of it, cannot be accessed by any possible continuation of execution, including the running of destructors, the object is considered inaccessible and the object becomes eligible for collection.
6. Finally, at some time after the object becomes eligible for collection, the garbage collector frees the memory associated with that object.

The behavior of the garbage collector can be controlled, to some degree, via static methods on the class System.GC. This class can be used to request a collection to occur, destructors to be run (or not run), and so forth.
Note:
Destructors are not inherited. Thus, a class has no destructors other than the one that may be declared in that class.

Since a destructor is required to have no parameters, it cannot be overloaded, so a class can have, at most, one destructor.
Destructors are invoked automatically, and cannot be invoked explicitly. An instance becomes eligible for destruction when it is no longer possible for any code to use that instance. Execution of the destructor for the instance may occur at any time after the instance becomes eligible for destruction.  (http://www.devx.com/dotnet/Article/33167/1954)

Table Variable vs Temporary Table (#, ##)

As temporary tables (#, ##) and table variables. While the differences between ##table (global temporary table) and #table (local temporary table) are well understood, there is a fair amount of confusion between #table and table variable.
The scoping rules of the table variable are similar to any other programming variables. For example, if you define a variable inside a stored procedure, it can’t be accessed outside the stored procedure. Incidentally, #table is very similar. So why did we create table variables? Well, a table variable can be very powerful when used with stored procedures to pass it as input/output parameters (new functionality available starting with SQL Server 2008) or to store the result of a table valued function. Here are some similartities and differences between the two:

• First, the table variable is NOT necessarily memory resident. Under memory pressure, the pages belonging to a table variable can be pushed out to tempdb.
• Second, when you create a table variable, it is like a regular DDL operation and its metadata is stored in system catalog.
• Third, transactional and locking semantics. Table variables don’t participate in transactions or locking.
• Fourth, the operations done on table variable are not logged.
• Fifth, no DDL is allowed on table variables. So if you have a large rowset which needs to be queried often, you may want to use #table when possible so that you can create appropriate indexes. You can get around this by creating unique constraints when declaring table variable.
• Finally, no statistics is maintained on table variable which means that any changes in data impacting table variable will not cause recompilation of queries accessing table variable. 

These are some of the drawbacks of Table Variable as compared to temporary tables:

• Non-clustered indexes cannot be created on table variables, other than the system indexes that are created for a PRIMARY or UNIQUE constraint. That can influence the query performance when compared to a temporary table with non-clustered indexes.
• Table variables do not maintain statistics like temporary tables can. Statistics cannot be created on table variables through automatic creation or by using the CREATE STATISTICS statement. Therefore, for complex queries on large tables, the lack of statistics may deter the optimizer to determine the best plan for a query, thus affecting the performance of that query.
• The table definition cannot be changed after the initial DECLARE statement.
• Tables variables cannot be used in a INSERT EXEC or SELECT INTO statement.
• CHECK constraints, DEFAULT values, and computed columns in the table type declaration cannot call user-defined functions.
• You cannot use the EXEC statement or the sp_executesql stored procedure to run a dynamic SQL Server query that refers a table variable, if the table variable was created outside the EXEC statement or the sp_executesql stored procedure. Because table variables can be referenced in their local scope only, an EXEC statement and a sp_executesql stored procedure would be outside the scope of the table variable. However, you can create the table variable and perform all processing inside the EXEC statement or the sp_executesql stored procedure because then the table variables local scope is in the EXEC statement or the sp_executesql stored procedure.

Table variables have the following advantages over temporary tables:

• Table variables, such as local variables, have a well defined scope at the end of which they are automatically cleared.
• Table variables result in fewer recompilations of a stored procedure as compared to temporary tables.
• Transactions that involve table variables last only for the duration of an update on the table variable. Therefore, table variables require less locking and logging resources. Because table variables have limited scope and are not part of the persistent database, transaction rollbacks do not affect them.