This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi, I have the following in LinqPad (I get the same error in the actual code)...
I get an SQL exception saying "SqlException: The multi-part identifier "t3.Id" could not be bound. The multi-part identifier "t3.BulletinBoardId" could not be bound. The multi-part identifier "t3.CreatedOn" could not be bound. The multi-part identifier "t3.DeletedOn" could not be bound. etc...." When I look at the generated SQL in LinqPad...
Clearly there is no t3 defined. If I try to run this SQL in Microsoft SQL Server Management Express I get the same error. If I replace t1 with t3 (or t3 with t1) then the query runs OK. It looks to me like the SQL generation is getting confused at some point. This LINQ query was running fine under LS 3. Any suggestions on a work around or bugfix? Regards, Felix |
|
|
Looking at the query I wonder if it is because the relevantParticipants query is nested twice. Perhaps when it is optimised it is losing track of the t3/t1 alias. |
|
|
I got it working by refactoring the query into a single multi-column join.
More readable/maintainable? maybe... It does still seem to me that there is a bug in the query optimiser. |
|
|
Thanks for reporting this - it will indeed be because the query with BoardParticipants has been included multiple times with LINQ this means that we have two distinct expression trees which will be equivalent in different parts of the tree, so as we part this we will alias this twice (t1 and t3 in this case). I am not too sure why the t3 instance has been stripped out of the query however, I would have expected that it would have included BoardParticipants twice. If its possible to send through a repro for this that would be much appreciated. The workaround as you have found is simply to simplify how your query is expressed so that duplication doesn't occur, particularly in this case where you actually want to refer to the same table twice in multiple parts of the query.
|
|