Archive for the ‘LINQ’ Category

SelectMany Example: Flatten Parent Child Association Into A Single List

October 28, 2011

I’m starting to get the hang of LINQ SelectMany now.

Here’s a great article which explains SelectMany better than any other I’ve read. For this James Etheredge is awarded the BTWT Golden Tadpole With Anachronistic Zeppelin for services to Brain Improvement.

So the key is to recognise that SelectMany needs a List to work on. Well, not a List exactly. SelectMany actually works on an IEnumerable. But to get started with SelectMany we can take the conceptual shortcut of thinking of SelectMany as working on instances of List.

So if I have a list of Tadpoles each of which contains a list of Zeppelins and I want to flatten that list I just say:

List (Of TadpoleZeppelins) tadZeps = tadpoles.SelectMany(tad =>
CreateTadpoleZeppelin(
tad.Zeppelins.ToList())).ToList();

CreateTadpoleZeppelin creates a list of TadpoleZeppelins out of a List of Zeppelins, like so:

CreateTadpoleZeppelin(List(Of Zeppelin) zeps)
{
List(Of TadpoleZeppelin) tadZeps = new List (Of TadpoleZeppelen)
zeps.ForEach(zep =>
{
TadpoleZeppelin tadZep = new TadpoleZeppelin();
tadZep.NumFins = zep.Tadpole.NumFins;
tadZep.HeliumCapacity = zep.HeliumCapacity;

tadZeps.Add(tadZep);
});

return tadZeps;
}

I think that’s pretty self-explanatory.

Footnote
If the example seems a bit weird just substitute ‘Customer’ for ‘Tadpole’ and ‘Order’ for ‘Zeppelin’

LINQ SubmitChanges throws Index Out Of Range Error

December 23, 2009

You’ll get this if you have Associations in your dbml file which do not reflect the reality of your database.

In my case I was given a dbml file (NOT MY BUG! NOT MY BUG!) that had spurious Associations in them. Like unwanted relatives these must be bought off sent to nunneries deleted.

My database tables are:

Product
Order
Customer
Student

I was doing an update on an Order record and got the Index Out Of Range error on SubmitChanges.

Inspecting the dbml, on the advice of this very helpful thread on Stack Overflow and also this one on MSDN LINQ Project General, there were LINQ Associations between Product->Order, Product->Customer and Product->Student.

The last two Associations were spurious. They shouldn’t have been there, specifically, there is no ProductID ForeignKey on Customer and no ProductID ForeignKey on Student either

Once I deleted the spurious, unwanted, grotesque, unneeded, and overall wrong Associations I was once again able to save my Order records during Update, so making the planet safe for Capitalism.

LINQ context.SubmitChanges() does not add record to database

May 8, 2008

This never happens.

If you think that context.InsertOnSubmit(entity) is not adding the entity to your Context then you are doing something wrong.

In my case, I had code like this:


ProductContext context = new ProductContext();
Product product = new Product();
product.Id = productId;
product.Name = productName;
product.Description = productDescription;

context.InsertOnSubmit(product);
context.SubmitChanges();

Totally straightforward, but when I checked the database, the Product table did not contain the new Product record I had created above. But this problem only occurred on our Integration Test server, not on our Dev box (Why?). So began my journey of pain….

I ran the program a few times and noticed that my EntitySet, context.Products, was increasing in number each time I passed through the AddProduct method snippet above, but the database table, Product, as viewed through VS Server Explorer did not have the same number of records as the context. WHY?!!! (Some of you have guessed already.)

I started Googling for help: “InsertOnSubmit fails”; “SubmitChanges does not save”; “LINQ insanity coronary apoplexy” etc. Then spake Thrifty Dave, our noble Team Leader: “Perhaps the Connection Strings are different on the Test box,” suggested Dave between mouthfuls of remaindered Sushi. My pangs of internal anguish commenced immediately. This had the ring of truth as well as the scent of slightly fermented Wasabi paste.

I checked the Connection Strings: yep, the Context on Integration Test was pointing to “ProductTest” database whereas the actual database I was looking at was “ProductLive”. Too simple. There was NO problem with context.SubmitChanges(). I was just looking at the wrong database. *blush* (Respectfully please now imagine a luminous red object larger than the Hindenburg and covered in Wasabi paste).

Moral Of The Story

context.SubmitChanges() always works. If you think its not working, then its your fault. Look elsewehere. Maybe check your ConnectionStrings.

Plausible Deniability

The reported bug was in a Windows Service which utilizes the same database as the main application. On the IntegrationTest server, the Windows Service app.config had its ConnectionString set to “ProductLive” database due to an error in our deployment scripts. My colleague, who wrote the Windows Service told me that data was not being found by the Windows Service and HE was checking “ProductLive”, based on the (faulty) Windows Service app.config.

So I believed what I was told.
But, yes, I should have checked, and I should have realised quicker what was going on

Life Force Depletion: Classified.