Merge Data Tables Easily

Many a times we face a situation where we have to merge data from multiple DataTable into single DataTable.  Previously we achieved this by iterating through the data rows in the DataTable and adding one by one into the single DataTable. This not only is memory consuming but also a bad practice.

To overcome this .net 4.0 now has a new DataTable function i.e. Merge(). The following program will make it more clear.

private static void DemonstrateMergeTable()
{
    DataTable table1 = new DataTable("Items");

    // Add columns
    DataColumn idColumn = new DataColumn("id", typeof(System.Int32));
    DataColumn itemColumn = new DataColumn("item", typeof(System.Int32));
    table1.Columns.Add(idColumn);
    table1.Columns.Add(itemColumn);

    // Set the primary key column.
    table1.PrimaryKey = new DataColumn[] { idColumn };

    // Add RowChanged event handler for the table.
    table1.RowChanged += new 
        System.Data.DataRowChangeEventHandler(Row_Changed);

    // Add ten rows.
    DataRow row;
    for (int i = 0; i <= 9; i++)
    {
        row = table1.NewRow();
        row["id"] = i;
        row["item"] = i;
        table1.Rows.Add(row);
    }

    // Accept changes.
    table1.AcceptChanges();
    PrintValues(table1, "Original values");

    // Create a second DataTable identical to the first.
    DataTable table2 = table1.Clone();

    // Add column to the second column, so that the 
    // schemas no longer match.
    table2.Columns.Add("newColumn", typeof(System.String));

    // Add three rows. Note that the id column can't be the 
    // same as existing rows in the original table.
    row = table2.NewRow();
    row["id"] = 14;
    row["item"] = 774;
    row["newColumn"] = "new column 1";
    table2.Rows.Add(row);

    row = table2.NewRow();
    row["id"] = 12;
    row["item"] = 555;
    row["newColumn"] = "new column 2";
    table2.Rows.Add(row);

    row = table2.NewRow();
    row["id"] = 13;
    row["item"] = 665;
    row["newColumn"] = "new column 3";
    table2.Rows.Add(row);

    // Merge table2 into the table1.
    Console.WriteLine("Merging");
    table1.Merge(table2, false, MissingSchemaAction.Add);
    PrintValues(table1, "Merged With table1, schema added");

}

private static void Row_Changed(object sender, 
    DataRowChangeEventArgs e)
{
    Console.WriteLine("Row changed {0}\t{1}", e.Action, 
        e.Row.ItemArray[0]);
}

private static void PrintValues(DataTable table, string label)
{
    // Display the values in the supplied DataTable:
    Console.WriteLine(label);
    foreach (DataRow row in table.Rows)
    {
        foreach (DataColumn col in table.Columns)
        {
            Console.Write("\t " + row[col].ToString());
        }
        Console.WriteLine();
    }
}

Choosing the Right Collection Class

In .net we have number of collection classes that are very useful in managing collections of object. But the question is which one should we use to get the best performance. The answer is that what is the scenario and the output that one requires from the collection, depending on which the selection of the collection type should be made. The following table explains the basic parameters for collections that should be kept in mind while selection the type of collection.

Collection	Ordered?	Contiguous Storage?	Direct Access?	Lookup Efficiency		Notes
Dictionary	No	Yes	Via Key	Key: O(1)		Best for high performance lookups.
Sorted Dictionary	Yes	No	Via Key	Key: O(log n)		Compromise of Dictionary speed and ordering, uses binary search tree.
SortedList	Yes	Yes	Via Key	Key: O(log n)		Very similar to SortedDictionary, except tree is implemented in an array, so has faster lookup on preloaded data, but slower loads.
List	No	Yes	Via Index	Index: O(1) Value: O(n)		Best for smaller lists where direct access required and no ordering.
LinkedList	No	No	No	Value: O(n)		Best for lists where inserting/deleting in middle is common and no direct access required.
HashSet	No	Yes	Via Key	Key: O(1)		Unique unordered collection, like a Dictionary except key and value are same object.
SortedSet	Yes	No	Via Key	Key: O(log n)		Unique ordered collection, like SortedDictionary except key and value are same object.
Stack	No	Yes	Only Top	Top: O(1)		Essentially same as List except only process as LIFO
Queue	No	Yes	Only Front	Front: O(1)		Essentially same as List except only process as FIFO

For more read this good article.

The 4 Types of Emails Programmers Receive

The 4 Types of Emails Programmers Receive

 

The Vague Email

Feature XYZ isn’t working. Please fix.

Provides next to no information other than at some point, a feature — possibly XYZ — didn’t function the way a specific user expected it to. Issue could be anything ranging from a catastrophic system failure to a simple misunderstanding on the part of the user. Usually requires a series of follow-up emails, phone calls, and conferences in order to clarify the problem at hand.

 

The End of the World Email

URGENT!!! System is down! NONE of our users can do XYZ! Please advise!!!11!

Usually flagged as important in Outlook and CC’ed to everyone in the user’s contact list. Grossly overstates the magnitude of the problem either to guarantee an expedited fix or simply because the user would rather yell at someone rather than bother checking. Rarely turns out to be as terrible as originally advertised. Unfortunately, that still won’t save you from having to put out all the fires the email started.

 

The Red Herring Email

Can you check if XYZ is working?

Actual problem winds up being completely unrelated to XYZ. Unfortunately, you won’t find that out until after you’ve spent several hours poring over code trying to envision the perfect storm of events that would have triggered a failure in XYZ.

 

The Ideal Email

When I do XYZ, ABC happens. I expected DEF to happen instead. Here are some screenshots showing what happened.

Clear, concise, and doesn’t make any assumptions about the issue at hand. Gives enough information for a programmer to at least approach the problem and is oftentimes sufficient without any additional follow-up. These are rare and far between, yet the amount of effort to type them up isn’t much more than any of the three other types of emails. Wouldn’t life be a lot simpler if all emails came in this format?


For more refer to this good article. I loved it..