I get an error with the message "The multi-part identifier "LPLA_2.Name" could not be bound." when using such query:

from t in metaData.Table1
select new { Result = t.StringColumn ?? t.Navigation.Name };

No inheritance here. StringColumn is nullable. Navigation was also nullable in my case, but one of the two fields was always filled.

• LLBLGen version and runtime library version? (http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=12769)

• Post the generated SQL.

Reproduced. It doesn't add the relationship in the field.

Sorry for all these linq issues, Deividas. After 2+ years we thought we had everything ironed out, there were hardly bugs mentioned in v3's linq provider anymore. Still we have some dark spots to cover it seems.

Looking into it.

Fixed. 'Coalesce' was a special case, as VB.NET emits it sometimes where the left side is only needed. And as it's a special case (yeah, linq provider code is fun ) it didn't benefit from the code elsewhere, where we pull relations discovered in projections to the main query. It now does that. See attached linq provider.

Otis wrote:

Sorry for all these linq issues, Deividas. After 2+ years we thought we had everything ironed out, there were hardly bugs mentioned in v3's linq provider anymore. Still we have some dark spots to cover it seems.

I used LLBLGen several years before and have very good memories about it. So I recommended it to my current employer. And it was very odd to me that every time I tried to write a semi-complex linq query, it failed. It seemed that LLBLGen supports only a fraction of linq features. At first it didn't even occur to me that these were bugs, I just thought that LLBLGen didn't support the features. Part of the problem was that most of the linq examples in documentation are very simple (except maybe the "Contains" examples), almost no information about inheritance, nothing about joins. It was very frustrating.

So I'm very glad that I turned to the forums. Somehow I realised that the problems I was facing were bugs and I had a chance to experience the famous LLBLGen support, which is as good as I remember from years before, maybe even better. And now I'm loving linq to LLBLGen.

Deividas wrote:

Otis wrote:

Sorry for all these linq issues, Deividas. After 2+ years we thought we had everything ironed out, there were hardly bugs mentioned in v3's linq provider anymore. Still we have some dark spots to cover it seems.

I used LLBLGen several years before and have very good memories about it. So I recommended it to my current employer. And it was very odd to me that every time I tried to write a semi-complex linq query, it failed. It seemed that LLBLGen supports only a fraction of linq features. At first it didn't even occur to me that these were bugs, I just thought that LLBLGen didn't support the features. Part of the problem was that most of the linq examples in documentation are very simple (except maybe the "Contains" examples), almost no information about inheritance, nothing about joins. It was very frustrating.

LINQ2LLBL has been tested for a long time for many users. It happens that eventually someone comes with an edge un-tested case, like you. Anyway, this feedback is very helpful to make the product better. So thanks.

Deividas wrote:

So I'm very glad that I turned to the forums. Somehow I realised that the problems I was facing were bugs and I had a chance to experience the famous LLBLGen support, which is as good as I remember from years before, maybe even better. And now I'm loving linq to LLBLGen.

Thanks for the feedback