Hello,

I've converted an existing application from v2.6 to v3 and now I'm faced with a problem with the Linq to LLBLGen queries.

In my entity definitions, I have different names for the element names and the target element names. For example my User-Entity has the element name (property) "Id" which will be "TUser_Id" in the underlying SQL-Table (Target element name of the entity).

When fetching an Entity by the classic way (FetchEntity) LLBLGen us the target name ("TUser_ID") to query the database but when using Linq to query the entity, the resulting SQL-Query use the element name ("Id") which doesn't exist in the SQL-Table. As result, I'm getting an error.

Any help is appreciated.

With best regards,

Ingbert

Which version (build number) of the LinqSupportClasses.dll are you using?

LLBLGen Pro Linq Support Classes library File version : 3.0.10.706 Product version : 3.0.10.706

I've downloaded the latest build of v3 on tuesday this week.

IngbertPalm wrote:

LLBLGen Pro Linq Support Classes library File version : 3.0.10.706 Product version : 3.0.10.706

I've downloaded the latest build of v3 on tuesday this week.

All our v2 queries run fine on v3, so I need a repro case, as your descriptions are too vague and I don't see how your situation is different from our test cases. Please specify in detail what we need to reproduce this, or better, create a small project (console app) on a known example db like northwind, adventureworks etc.

Otis wrote:

IngbertPalm wrote:

LLBLGen Pro Linq Support Classes library File version : 3.0.10.706 Product version : 3.0.10.706

I've downloaded the latest build of v3 on tuesday this week.

All our v2 queries run fine on v3, so I need a repro case, as your descriptions are too vague and I don't see how your situation is different from our test cases. Please specify in detail what we need to reproduce this, or better, create a small project (console app) on a known example db like northwind, adventureworks etc.

Hello Otis,

Attached you will find a small console application who will demonstrate the issue.

I’ve created a new LLBLGen project from the AdventureWorks sample database. I’m using SQL-Server 2008 64 Bit on Windows 7 64 Bit and Visual Studio 2010 Premium.

I’m able to reproduce the issue on different computers.

Let me know if you need other informations.

With best regards

Ingbert

It's a VB.NET specific thing. I can't reproduce it in C#, though I can reproduce it in VB.NET.

I also can't reproduce it if I use: Dim cnt = userQuery.CountColumn(Function(u) u.Id)

This produces a proper query. I think what happens is a problem with how VB.NET's compiler sees 'Count()'. It should see it as a call to the Aggregate Extension method 'Count()'. However it compiles it as a MemberExpression as it sees it as an access to the Count property instead.

When using .Count(), I get: value(SD.LLBLGen.Pro.LinqSupportClasses.DataSource2`1[LinqTest2.EntityClasses.UserEntity]).Where(TUser => (TUser.Id == 10)).Select(TUser => TUser).Count()

as expression tree, though that still can be the property access, so I've to dig deeper with the expression tree visualizer. You should use CountColumn() instead as I illustrated above to work around this VB.NET specific thing. We'll see if we can add a check for this to the linq provider.

We already had a method which stripped out the useless .Select(x=>x) call which was introduced by the VB.NET compiler (the cause of this problem), however the method marked the source of the .Select() always as a candidate for a projection, which should be left to the wrapping expression.

So in the next build it will work properly.

Otis wrote:

We already had a method which stripped out the useless .Select(x=>x) call which was introduced by the VB.NET compiler (the cause of this problem), however the method marked the source of the .Select() always as a candidate for a projection, which should be left to the wrapping expression.

So in the next build it will work properly.

I've downloaded the latest build and it works now

Thank you for your help!