Zeeshan Hirani

Most of us don't have to worry about how linq does all the magic in the background of persisting our objects and syncing up our primary keys that are auto generated in the database. However if you are manually creating your class it is good to know what attributes are must and required to be able to save objects to the database and how to sync the auto generated id created by the database with property defined as Primary column in the entity class. If you want to sync up primary key identity column with entity member when you insert an instance of the entity class, you have to set the column defined as Primary Key column and set the column as IsDbGenerated to true. Here is a very simple example of a datacontext and Categories class that has IsDbGenerated set to true for CategoryID column.

For every column in the database, linq to SQL generates a property that maps a particular column in the database to the property defined on the entity class. However if you look at the setter property generated by the designer, it has all the details which raises events that notifies to the subscribers that property has changed. Basically for a property called ProductName, the designer generated code will raise a before and after event. Further more the setter also notifies the tracking service that property has been changed by the end user code. Due to this reason, linq to SQL is able to generate the appropriate SQL statement to send the changes to the database. However, when we fetch an entity from the database, linq to SQL has to go through the same process of assigning the property value by reading the column from the database, which is totally not required. We do not want linq to assign our property using the setter because the values assigned would be tracked and there is no point in tracking the value since it was not changed by the end user code. This is where we can use the attribute called Storage which specified the private level variable that linq to SQL can directly use to by pass property accessors and interacts directly with our field level variable.  By default the designer ensures this for your by making use of Storage Attribute. However there is nothing stopping you from changing this behavior if you want linq to SQL to use property accessors and go through your business logic defined inside your setter. Here is a an example of the code generated by the linq to SQL designer.

Table valued function are nice way to apply further transformations to your linq queries. The reason is, they return IQueryable instead of stored procedure returning IEnumerable. I will not delve into the original problem that I was facing at work, but try to come with an example that identifies the issue I was facing with linq to SQL.

Joins in linq to SQL are not any different than SQL server. Join basically joins the results of two or more table and shows only record that match in the outer sequence  that has rows present in the inner sequence. Here is an example that illustrates that.

There are several query operators available in Linq that supports the concept of Default like SingleOrDefault or FirstOrDefault etc. Default returns the default value for that type. If the type is integer the default would be an int. If the type is string that the default would be a null. However if type is nullable ints than the default value would be nullable<int>. Here is an example of that.

Its pretty amazing that querying concept has completely eliminated my use of loops and if statements. Today I was playing around with someone's class library which was pretty big. I decided to print out all the methods and its overloaded versions available. Here is an example of printing out the methods available in int class and the display also shows how many times a particular method is overloaded.

If you have not used All operator with LINQ query, you will realize that ALL operator will include collection that meet the criteria condition as well include collection that is empty. So if you have a query where you are trying to find customers who have all orders that are placed in city of London, than your customer results would include orders from city of London as well customers who have not place any orders at all. Let's take a look at an example.

I am pretty sure I checked all my alternatives but I cant seem to find a way to do server side paging with ListView control and DataPager. Most of my existing code base does not use object datasource or LinqDataSource control which exposed a property called SelectCountMethod that gets the value of the total rows available for that select clause. Usually for server side paging you provide the rows which the user can see which is the startrow and maximum rows and than for the DataPager to build its UI, you provide method for SelectCountMethod that retrieves the count of actual rows available. But how do you accomplish this task when you are not using objectdatasource control. Well DataPager exposes a property called TotalRowCount whose value get set by the object datasource or linq datasource control. However this property is only readonly, which you cannot set if you are manually binding the ListView Control. I am not sure why the architecture was done this way which forces the use of a specific control to achieve server side paging.