Zeeshan Hirani

One of the recent trick I discovered with linq to SQL queries is, when you want to filter records, you do not necessarily have to filter by primary key like CustomerID. Instead you can compare object references and linq to SQL in the background would convert the linq query as comparison based on primary key of that table. For instance if I want to find all the orders for a particular customer, I would write a query like this

The default configuration for asp.net Ajax simply shows an alert box if your asynchronous postback causes an exception. This may not be the appropriate way you want to handle exceptions in your application. Here is a simple markup that illustrates this behavior.

If you ever wanted to refresh a portion of your page on a certain interval, it does not get any easier with asp.net Ajax. Simply surround the content with an Update Panel and trigger the update of the Update Panel using the timer control. Here is the markup that illustrates this example.

The order in which you apply where and join in SQL server does not matter too much. One of the reason is that SQL server has its own optimizer built in which knows how to rewrite the query so it is optimized for best performance. However we don' get that luxury with Linq to objects. Therefore it is essential that you understand how to write your query so that it gives you maximum efficiency. For instance apply your filter before joining because filtering would reduce the number of rows returned and as a result there would be fewer rows that you would need to join against. Here is a simple example that illustrates the performance gain that you would get when you apply the where clause before the join statement.

For many years working in SQL server environment and writing dozens of joins, I never cared which table needs to come first and which one comes second. The reason was SQL server would use table statistics to determine best way to join two tables. However we don't get this luxury when we are writing Linq to object queries in C# 3.0. For instance if you have two sequences in memory and you have to join those two sequences, than always use the smaller sequence on the right side of your query and the larger sequence on the left side. It makes a considerable difference in performance. To prove that there is a big difference in the time it takes for the query to execute I will put a small sequence on the right side and run the query to see how long it takes.

Yesterday I was writing a Linq query that required joining two tables and mistakenly reversed the order of columns being joined. Surely enough compiler complained. I was pretty surprised why my code did not compile. I am sure many of you are SQL gurus and must have written joins and never cared that left column in the join clause must always come from the left table and right column in the join clause must come from right table. SQL server and many other database engines are pretty lenient in it. However Linq flavor requires your key selectors in the join clause must be in proper order. Basically left key of the key selector must come from left sequence or outer sequence. The right key of the key selector should come from right or inner sequence. Here is an example which C# compiler does not like because the order of the key selector is reversed.

On one of my projects I had the need to intercept the begin request and pageloaded event of page request manager. Begin request is an event raised by page request manager when a control inside of an UpdatePanel postback to the server. The event is raised just before the request is sent to the server. PageLoad event is a similar event but it gets raised the after the request has been received from the server and appropriate Update Panels have been updated. When I registered for pageloaded event and was manipulating the controls based on the data data received from the server, I was getting weird behaviors after resetting variables I had declared globally. To investigate the matter I put debug statements and sure enough confirmed that PageLoad event was firing twice. Here is an example that displays that behavior.

Linq to SQL supports both stored procedures and functions that can return result set. However there is a clear distinction in each approach. When you are using store procedures the data is returned as IEnumerable<T>. What this means is in the Linq query where you are calling the stored procedure, if you want to further apply more query operator meaning further filter the result  than that portion of the query will get executed as Linq to objects without you being aware of it. This could be great bottle neck if your stored procedure returns thousands of record and your applying filter that gets applied in memory instead of being sent as a part of query that gets executed on SQL server. In contrast if you are using table valued functions, data returned is in the form of IQueryable meaning you can further refine your query based on filters that you require. Those filters would become part of the SQL query that gets sent to the SQL server. To demonstrate this behavior I will start of with a table valued function and a stored procedure that returns customers based on city parameter.