Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'SqlException: The multi-part identifier xxxx could not be bound' for a query scenario that was working in 2.2 that doesn't work in 3.0 #18514

Closed
yepeekai opened this issue Oct 22, 2019 · 3 comments · Fixed by #18520
Assignees
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. customer-reported type-bug
Milestone

Comments

@yepeekai
Copy link

The following query was working in 2.2 but fails in 3.0. The original query is more complex that this but I narrowed it down to this:

var result = dbSetMembre
    .Take(25)
    .Select(a => new
    {
        aId = a.Id,
        a1 = a.TelephonesMembres
        .Select(b => new
        {
            bId = b.Id
        })
        .FirstOrDefault(),
        a2 = a.CourrielsMembres
        .Select(c => new
        {
            cId = c.Id,
        })
}).ToList();

generates the following sql:

exec sp_executesql N'SELECT [t].[Id], [t2].[Id], [t3].[Id]
FROM (
    SELECT TOP(@__p_0) [m].[Id]
    FROM [Membre] AS [m]
) AS [t]
LEFT JOIN (
    SELECT [t1].[Id], [t1].[MembreId]
    FROM (
        SELECT [t0].[Id], [t0].[MembreId], ROW_NUMBER() OVER(PARTITION BY [t0].[MembreId] ORDER BY [t0].[Id]) AS [row]
        FROM [TelephoneMembre] AS [t0]
    ) AS [t1]
    WHERE [t1].[row] <= 1
) AS [t2] ON [t].[Id] = [t2].[MembreId]
OUTER APPLY (
    SELECT [c].[Id]
    FROM [CourrielMembre] AS [c]
    WHERE [m].[Id] = [c].[MembreId]
) AS [t3]
ORDER BY [t].[Id], [t3].[Id]',N'@__p_0 int',@__p_0=25

which result with the following error: SqlException: The multi-part identifier "m.Id" could not be bound. When analyzing the generated sql, we can see that the outer apply is using m.Id from a sub query but it must use the result of that sub query: t.Id

Further technical details

EF Core version: 3.0
Database provider: Microsoft.EntityFrameworkCore.SqlServer
Target framework: .NET Core 3.0
Operating system: windows 7
IDE: Visual Studio 2019 16.3.5

@smitpatel
Copy link
Contributor

My guess is this has same root cause as #17809 but simple repro.

@yepeekai
Copy link
Author

This indeed look like the same problem. I see the work around but it is difficult to apply in our case because we have a framework to generate/reuse expressions and it is not possible to know all the places where this problem can occur... I see that ajcvickers remove the 3.1 milestone :( Do you think it can make its way back in it? Thanks.

@smitpatel smitpatel self-assigned this Oct 22, 2019
smitpatel added a commit that referenced this issue Oct 22, 2019
…on into subuquery

Issue: When converting correlation to join, we add the join key columns to projection to make sure they are always available.
We had logic that if projection contains any columns then projection mapping is already applied to projection.
But in above case that is incorrect.
That leaves us with incorrect EntityProjection which fails in further translation as multi-part identifier could not be bound.

We should always lift projectionMapping during Pushdown unless projectionMapping is applied which can be checked through type.

This scenario does not work for owned/weak types due to #18519

Resolves #18514
smitpatel added a commit that referenced this issue Oct 22, 2019
…on into subuquery

Issue: When converting correlation to join, we add the join key columns to projection to make sure they are always available.
We had logic that if projection contains any columns then projection mapping is already applied to projection.
But in above case that is incorrect.
That leaves us with incorrect EntityProjection which fails in further translation as multi-part identifier could not be bound.

We should always lift projectionMapping during Pushdown unless projectionMapping is applied which can be checked through type.

This scenario does not work for owned/weak types due to #18519

Resolves #18514
smitpatel added a commit that referenced this issue Oct 23, 2019
…on into subuquery

Issue: When converting correlation to join, we add the join key columns to projection to make sure they are always available.
We had logic that if projection contains any columns then projection mapping is already applied to projection.
But in above case that is incorrect.
That leaves us with incorrect EntityProjection which fails in further translation as multi-part identifier could not be bound.

We should always lift projectionMapping during Pushdown unless projectionMapping is applied which can be checked through type.

This scenario does not work for owned/weak types due to #18519

Resolves #18514
@smitpatel smitpatel added this to the 3.1.0 milestone Oct 23, 2019
@smitpatel smitpatel added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label Oct 23, 2019
@yepeekai
Copy link
Author

Thank you very much

@ajcvickers ajcvickers modified the milestones: 3.1.0, 3.1.0-preview2 Oct 24, 2019
@ajcvickers ajcvickers modified the milestones: 3.1.0-preview2, 3.1.0 Dec 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. customer-reported type-bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants