LINQ: more like "Luckily I Never Quit"

I’ve been using LINQ quite a bit lately. As the blog title says: luckily, I never quit.

There are a lot of things to get used to with LINQ. For one, it uses deferred queries. When you make a change, you must submit changes before the change is reflected in the database. Yes, this mirrors the actions when working directly with a database (COMMIT), but when you’re thinking of it as application logic, it seems counter-intuitive.

<aside>

At school, I’m in a class called INFO 465: Projects in Information Systems. The class is slow-going. At VCU, there are three tracks of studies in Information Systems: Application Development, Business Analysis, and Network Administration. Unfortunately, most of the people in BA and Networking are there because they don’t want to do any programming at all. You would think a class geared to using your course skills would accommodate each track equally?

That’s not the case in this class. There are two projects. One is individual work and the other is group work. The individual project is really just a large programming assignment to create an “Enterprise System” for a landscaping company. Luckily, the company consists of the landscaper, a truck, and his helper.

Anyway, to get back on track, we’re allowed to do our project any way we want. Most of the people in the class chose to do Windows Forms using VB.NET examples provided by the teacher. Good luck with that! I chose to use ASP.NET, AJAX, Web Services, and LINQ. I chose this route because I wanted this class to be a learning experience, not just a copy-paste session for 3 hours a week.

</aside>

Back to LINQ. To be quick about development, I’ve decided to use GridViews, DetailsViews, and LinqDataSources. Every time I try to link a LinqDataSource to a GridView’s selected key, I get this message:

Operator '==' incompatible with operand types 'Int32' and 'Object'

Here is an example of the LinqDataSource that throws this error:

<asp:LinqDataSource ID="srcSelectedOrder" runat="server"
        ContextTypeName="INFO465_First_Web.DatabaseMaps.OrdersDataContext"
        EnableDelete="True" EnableInsert="True" EnableUpdate="True" TableName="Orders"
        Where="Id == @Id">
        <WhereParameters>
            <asp:ControlParameter ControlID="GridView1" Name="Id"
                PropertyName="SelectedValue" Type="Int32" />
        </WhereParameters>
    </asp:LinqDataSource>

The problem is where you have the Where clause “Id == @Id”. For some reason, the data source thinks @Id is an object instead of an Int32, even though Type=”Int32″ in the WhereParameters.

The fix is the change this to Where=”Id == Int32?(@Id)”. I don’t know why this is. I mean, if you’re taking a primary key as the DataKeyName, it is being passed as Int32 in the WhereParameters, why do you have to cast it? Maybe the LinqDataSource automatically converts Id == @Id to an SQL query that would look like “Id == ‘2’”, and you have to cast to Int32 explicitly so it will look like “Id == 2” in the query? Again, this is another place that LINQ just seems backwards.

Here is the fixed data source:

<asp:LinqDataSource ID="srcSelectedOrder" runat="server"
        ContextTypeName="INFO465_First_Web.DatabaseMaps.OrdersDataContext"
        EnableDelete="True" EnableInsert="True" EnableUpdate="True" TableName="Orders"
        Where="Id == Int32?(@Id)">
        <WhereParameters>
            <asp:ControlParameter ControlID="GridView1" Name="Id"
                PropertyName="SelectedValue" Type="Int32" />
        </WhereParameters>
    </asp:LinqDataSource>

(I always format my code with http://www.manoli.net/csharpformat/)