version 2.6 (v2.0.50727)

I have an Group table with a ParentGroupID column (allows nulls). When I am projecting, I am trying to dig three levels deep, but for some reason, the very last level is always the level below it. for example, zone and region always have the same ids. Any ideas?

Also, we are not permitted here to upgrade to version 3.0 yet.

Thanks!

            var instances =
                    (from i in MetaData.ProcessRoundIssueInstance
                     where i.Active && i.IsComplete && i.ProcessRound.ProcessContest.Active
                        && (i.ProcessRound.ProcessContest.BeginDate <= date && i.ProcessRound.ProcessContest.EndDate >= date)
                     select new SubmissionDTO
                     {
                         ProcessRoundIssueInstanceID = i.ProcessRoundIssueInstanceID,
                         ProcessRoundTypeId = i.ProcessRound.ProcessRoundTypeID,
                         TransactionId = i.TransactionID,
                         Amount = i.Transaction.Quantity,
                         BAC = i.GroupID.GetValueOrDefault(),
                         District = i.Group.ParentGroupID.GetValueOrDefault(),
                         Zone = i.Group.Group.ParentGroupID.GetValueOrDefault(),
                         Region = i.Group.Group.Group.ParentGroupID.GetValueOrDefault()

                     }).ToList();

I am trying to dig three levels deep, but for some reason, the very last level is always the level below it. for example, zone and region always have the same ids. Any ideas?

Not sure I understand you correctly. But are you sure of the data int he database, if you checked the data there and it's not what you get from the query, then try to examine the generated SQL queries and run them manually against the database and check the data returned.

(Edit)

version 2.6 (v2.0.50727)

That's not the runtime version number (build number). Please check this thread to know how to get the correct one: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=7717

Walaa wrote:

I am trying to dig three levels deep, but for some reason, the very last level is always the level below it. for example, zone and region always have the same ids. Any ideas?

Not sure I understand you correctly. But are you sure of the data int he database, if you checked the data there and it's not what you get from the query, then try to examine the generated SQL queries and run them manually against the database and check the data returned.

Yes, the data is there, it works properly with Linq to SQL and EF. Not sure what tables in Northwind have a ParentId column, but if there is one, try doing the following:

Table.Parent.Parent.Parent.ID

MarcoP wrote:

Walaa wrote:

I am trying to dig three levels deep, but for some reason, the very last level is always the level below it. for example, zone and region always have the same ids. Any ideas?

Not sure I understand you correctly. But are you sure of the data int he database, if you checked the data there and it's not what you get from the query, then try to examine the generated SQL queries and run them manually against the database and check the data returned.

Yes, the data is there, it works properly with Linq to SQL and EF. Not sure what tables in Northwind have a ParentId column, but if there is one, try doing the following:

Table.Parent.Parent.Parent.ID

Which runtime library version are you using? (refer to my previous message, please).

ORM 2.6.10.421 Linq 2.6.10.315

Testing it. (Hang On).

(Edit) Reproduced indeed.

Northwind has the ReportsTo column in the Employee table. Repro code:

            var q =
                (from emp in metaData.Employees
                 where emp.EmployeeId == 6
                 select new
                            {
                                id = emp.EmployeeId,
                                id2 = emp.Employees.EmployeeId,
                                id3 = emp.Employees.Employees.EmployeeId

                            });

According to Northwind default data, the result should be (6, 5, 2), but it's showing (6, 5, 5). (note: employee.Employees is the Employee entity to whom the employee reports).

Looking into it...

Reproduced. Also in v3. We'll look into it.

Interesting thing is that the second join is missing.

Otis wrote:

Reproduced. Also in v3. We'll look into it.

Interesting thing is that the second join is missing.

Thanks for looking into guys.

MarcoP wrote:

Otis wrote:

Reproduced. Also in v3. We'll look into it.

Interesting thing is that the second join is missing.

Thanks for looking into guys.

Will be tomorrow (thursday) that we have something for you though, I hope you can wait that long

a workaround with 'let' also fails...

Otis wrote:

MarcoP wrote:

Otis wrote:

Reproduced. Also in v3. We'll look into it.

Interesting thing is that the second join is missing.

Thanks for looking into guys.

Will be tomorrow (thursday) that we have something for you though, I hope you can wait that long

a workaround with 'let' also fails...

Sure! Right now I just added the 3 joins to the query, but it looks soo much cooler to just do it inline!

MarcoP wrote:

Otis wrote:

MarcoP wrote:

Otis wrote:

Reproduced. Also in v3. We'll look into it.

Interesting thing is that the second join is missing.

Thanks for looking into guys.

Will be tomorrow (thursday) that we have something for you though, I hope you can wait that long

a workaround with 'let' also fails...

Sure! Right now I just added the 3 joins to the query, but it looks soo much cooler to just do it inline!

Luckily you don't have to see the code making that inline stuff possible, the coolness will be sucked right out of the query

glad it at least has 1 workaround . Will get a fix for you tomorrow

It's a problem which can't be fixed at this point. The problem is this: emp.Employee gets the same alias in: emp.Employee.SomeField and emp.Employee.Employee.SomeField

as it's the same target. This is working and OK.

However, the second Employee in emp.Employee.Employee is seen as the same property as emp.Employee, as it is too a property of an Employee type. And it thus gets the same alias as emp.Employee. This isn't correct, but the fix for this is not easy: the awareness of what a member represents has to be re-architected, as the path to the member apparently also has to be stored with the member to obtain the alias (or another solution, whatever it takes).

This is a problem which we can't fix at this point. It occurs if you dive into a relationship with self. We have planned to re-architecture this alias assignment for our linq provider in the future so also other edge case alias issues are solved.

So for now, use the uncool join workaround

No worries!