UPDATE I tested this initially with EmployeeID and noticed the strange behavior. Writing this blogpost I thought the max of the employeeID was a little artificial, so I changed that in OrderDate. But... what happened (see my reply to this blogpost below in the comments) ? When o.OrderDate is used, the VB.NET compiler produces a proper expression tree! But when EmployeeID is used, it doesn't. Both are nullable types. When using CustomerID it also works properly. It's beyond me why it fails to produce a proper expression tree when EmployeeID is used. Nevertheless, the advice I gave below is still valid: do yourself a favor and call the aggregate extension methods of All, Any, Max, Min, Sum etc. when you want to obtain these values from a set in a scalar query.
Tomorrow, May 22nd, and Friday, I'm present at the Microsoft DevDays 2008 in Amsterdam. I'm told we get special t-shirts, so it shouldn't be hard to find me . I'll be at the Microsoft Community Booth or in some sessions. If you want to say hi, please stop by! See you tomorrow!
Danny Simmons wrote a marketing piece about the project he's been working on for so long: "Why use the Entity Framework?". I don't expect Danny to be unbiased towards his own work, so at first I just ignored it: Microsoft produces these kind of 'use our stuff, it's better than sliced bread'-articles a dozen times a day. However, this particular article seems to be a discussion subject and is supported by non-Microsoft people on other blogs, so it's time to stop ignoring it and start to refute the contents of the article, despite it being marketing. After all, it doesn't look like it's marketing.
Imagine, you're sitting at your desk and you're using the Linq to Sql designer in VS.NET 2008 and you have, say, 50 entities in your model. You're happy about how things are progressing. It took a while to get the model set up, considering the wicked table and field names they cooked up in the DBA dungeon, but after some swearing and too much caffeine, it's done. The model which is smiling back at you is what you had in mind.
Rain slams against the window and the DBA you have heard about but never had the chance to meet in person, walks into your office and with her whiskey-shaped voice she almost whispers into your left ear:
"Son, I've updated a few tables in your catalog schema, hope you don't mind. See ya!"
Before you can ask her why she found it necessary to do such a terrible thing to you, she's dissapeared, back to her basement.
In shock, you stare at your shiny Linq to Sql designer, in it your 50 entities in full glory. Which tables were changed? What has she changed? WHAT!? You start telling yourself not to panic, when the idea of checking manually each and every of those 50 tables for changes, manually rebuilding the Linq to Sql model, re-doing your inheritance hierarchies, renaming the fields is causing a slight increase in sweat production. Why did you decide to wear this grey shirt to work, today!
In the latest public preview of Microsoft's Dynamic Data, they've added something else besides what's publicly advertised: support for 3rd party O/R mappers!
A couple of weeks ago, Bryan Reynolds mailed me about LLBLGen Pro support in MS Dynamic Data. I initially hadn't payed much attention to Microsoft's upcoming Dynamic Data initiative, as it's more geared towards web developers and was Linq to Sql / Entity Framework only as it seemed. He gave me a demo of Dynamic Data using Shared View (which works pretty well) and it got my attention. It's a clean, easy to use technology to get smaller websites which have to deal with data-entry, up and and running in no time.