When an EntityCollection isn't an IEnumerable...

I usually convert all my entity collections to plain old Arrays and I use the List.ToArray method to make the conversion. I push the data into a List via the constructor by casting the needed data to an IEnumerable.

This all goes well when I do a:
var data = (from iterEntity in Db.Table
select iterEntity);

I can do a:
var myList = new List((IEnumerable)data);
MyEntityType[] myArr = myList.ToArray();


However, when I select a set of related entities like so:
var data = (from iterOtherEntity in Db.OtherTable
where iterOtherEntity.refId = 911
select iterOtherEntity.MyEntities);

I can no longer cast data to an IEnumerable type, and so can't push data into a List via its constructor... I now have to write a foreach loop to do the same conversion to an array. :-(


UPDATE: There is an AsEnumerable extension method that you could try on the EntityCollection object (data). I didn't get a chance to try it yet, but I will as soon as I boot up in Windows again.

Linq-to-Entities doesn't support Collection.Contains

My Linq-to-Entity woes just won't come to an end. I tried doing a query like:
var rset = (from iterRow in db.TableA
where myArray.Contains(iterRow.Id)
select iterRow);

...but I just get the exception along the lines of:
LINQ to Entities does not recognize the method 'Boolean Contains(Int32)'
method, and this method cannot be translated into a store expression.

As the Linq to Entities framework (from .NET 3.5 SP1) still doesn't support the Contains method, that just one more thing that makes me wonder why the stars didn't reveal that Linq to SQL would be a better choice for my project.

There's a solution suggested here (scroll down to the post by Hongye Sun from Microsoft - no pun intended) that I didn't try out yet, but there is another post here saying the solution was successful.

LINQ to Entity Joins

Joins with LINQ-to-Entity are pretty straightforward - you don't have to write join conditions manually!

However, sometimes you do get an error that looks a little like this:

An expression of type PkTableEntity is not allowed in a subsequent from clause in a query expression with source type System.Data.Objects.ObjectQuery<FkTableEntity>. Type inference failed in the call to SelectMany.

It simply means that you've put your tables in the wrong order. I did something like this:

var rset = (from iterFkEntity in objDbEntities.FkTableEntity
from iterPkEntity in iterFkEntity.PkTableEntities
where iterPkEntity.ColumnA == 3
select iterFkEntity);

To correct it, I simply had to flip over the PkTable and the FkTable and turn it into:

var rset = (from iterPkEntity in objDbEntities.PkTableEntity
from iterFkEntity in iterPkEntity.FkTableEntities
where iterPkEntity.ColumnA == 3
select iterFkEntity);

Re-compile and the error is gone!

LINQ to SQL and Entity Framework

Ling to SQL and Entity Framework performance analysis

View more presentations from AlexMerle. (tags: programming orm)

LINQ to Entity Trash

I know, I know, everyone's talking about usin LINQ to Entities instead of LINQ to SQL, but there's so much that simply doesn't work when using LINQ to Entities.

First off, if you need to run a stored procedure that has nothing to do with any of the entities you are working with, the Entity framework simply can't handle it.

Secondly, there's the lack of support for using Contains to mimic SQL's IN operator. (You can use the Contains method as the equivalent of SQL's LIKE)

The Entity framework does have potential and version 2.0 is something I'm really looking forward to, but what I'm saying is that it is just not fully developed to use in all of your applications yet.

System.Data.Linq.Table: Beta 2 to RTM

If you've been following Microsoft technologies for a while, you probably noticed that when the technology goes into RTM, there are changes in method names and syntax (remember the exception handling syntax with SQL Server 2005 T-SQL in beta?). The same goes for LINQ.

When trying out code samples from the Beta 2 days, you'll probably want to note the following change to the method names of the System.Data.Linq.Table class:




The Add, AddAll, Remove and RemoveAll methods have been renamed to InsertOnSubmit, InsertAllOnSubmit, DeleteOnSubmit and DeleteAllOnSubmit, respectively. This is mostly because database developers look for methods with names that resemble the SQL statements (SELECT, INSERT, UPDATE, DELETE) and because these methods do not immediately add or remove the data from the table like you would expect if you've been working with collection types.

If you haven't updated your source code yet, you'll end up with the following compilation error:
System.Data.Linq.Table does not contain a definition for 'Add' and no extension method 'Add' accepting a first argument of type System.Data.Linq.Table could be found (are you missing a using directive or an assembly reference?)