Ошибка не удалось привязать составной идентификатор

More than likely your issue is that you are logged in using a database user whose default schema is different than the schema of the table from which you are selecting (or has no default schema).

For example: Say you have 2 schemas in your database, dbo and reports. Your database user was setup with a default schema of dbo. If you have a table in a reports schema reports.table1, and there is not a synonym in the dbo schema for dbo.table1 that points to reports.table1, then you will get this error if you do not specify the schema when selecting the field name.

NOTE: this appears to work in SQL 2008 R2, but when I tested in SQL 2005 then I received the error:

Msg 4104, Level 16, State 1, Line 1 The multi-part identifier
«TestTable.TestField» could not be bound.

You can check the default schema for your user by using this query:

select p.name, p.default_schema_name 
from sys.database_principals p 
order by p.name

A way to get around this is by using table alias’ in your query, or to specify the full path to the table as you mentioned in OP.

select t.[FieldName] 
from [SchemaName].[TableName] as t

MSSQL Как исправить ошибку Не удалось связать составной идентификатор

Я видел похожие ошибки на SO, но не нашел решения своей проблемы. У меня есть такой SQL-запрос:

SELECT DISTINCT a.maxa , b.mahuyen , a.tenxa , b.tenhuyen , ISNULL(dkcd.tong, 0) AS tongdkcd FROM phuongxa a , quanhuyen b LEFT OUTER JOIN ( SELECT maxa , COUNT(*) AS tong FROM khaosat WHERE CONVERT(DATETIME, ngaylap, 103) BETWEEN 'Sep 1 2011' AND 'Sep 5 2011' GROUP BY maxa ) AS dkcd ON dkcd.maxa = a.maxa WHERE a.maxa <> '99' AND LEFT(a.maxa, 2) = b.mahuyen ORDER BY maxa; 

Когда я выполняю этот запрос, результат ошибки: Не удалось связать составной идентификатор «a.maxa». Зачем? P / s: если я разделю запрос на 2 отдельных запроса, он будет работать нормально.

SELECT DISTINCT a.maxa , b.mahuyen , a.tenxa , b.tenhuyen FROM phuongxa a , quanhuyen b WHERE a.maxa <> '99' AND LEFT(a.maxa, 2) = b.mahuyen ORDER BY maxa; 

SELECT maxa , COUNT(*) AS tong FROM khaosat WHERE CONVERT(DATETIME, ngaylap, 103) BETWEEN 'Sep 1 2011' AND 'Sep 5 2011' GROUP BY maxa; 

• Есть ли phuongxa таблица включает столбец maxa?
• 1 Что произойдет, если вы добавите группу maxa, tang — сразу после 5 сентября 2011 года.
• Да, было. Если я разделю запрос на 2 подзапроса, он будет работать нормально
• Похоже, вы выполняете не ту базу данных. Добавьте оператор «USE [имя базы данных]» в начало запроса и посмотрите, по-прежнему ли вы получаете ошибку.
• 1 Нет, как я сказал выше, если я разделю запрос на 2 отдельных запроса, он выполнится нормально.

Вы смешиваете неявные соединения с явными соединениями. Это разрешено, но вы должны знать, как это делать правильно.

Дело в том, что явные объединения (те, которые реализованы с использованием JOIN ключевое слово) имеют приоритет над неявными (объединение «запятая», где условие объединения указано в WHERE пункт).

Вот краткое описание вашего запроса:

SELECT … FROM a, b LEFT JOIN dkcd ON … WHERE … 

Вы, вероятно, ожидаете, что он будет вести себя так:

SELECT … FROM (a, b) LEFT JOIN dkcd ON … WHERE … 

то есть комбинация таблиц a а также b соединяется со столом dkcd. На самом деле то, что происходит,

SELECT … FROM a, (b LEFT JOIN dkcd ON …) WHERE … 

то есть, как вы, возможно, уже поняли, dkcd присоединяется специально против b и только b, то результат соединения объединяется с a и отфильтровали дальше с WHERE пункт. В этом случае любая ссылка на a в ON пункт недействителен, a неизвестно на тот момент. Вот почему вы получаете сообщение об ошибке.

На вашем месте я, вероятно, попытался бы переписать этот запрос, и одним из возможных решений могло бы быть:

SELECT DISTINCT a.maxa, b.mahuyen, a.tenxa, b.tenhuyen, ISNULL(dkcd.tong, 0) AS tongdkcd FROM phuongxa a INNER JOIN quanhuyen b ON LEFT(a.maxa, 2) = b.mahuyen LEFT OUTER JOIN ( SELECT maxa, COUNT(*) AS tong FROM khaosat WHERE CONVERT(datetime, ngaylap, 103) BETWEEN 'Sep 1 2011' AND 'Sep 5 2011' GROUP BY maxa ) AS dkcd ON dkcd.maxa = a.maxa WHERE a.maxa <> '99' ORDER BY a.maxa 

Здесь таблицы a а также b сначала соединяются, затем результат соединяется с dkcd. По сути, это тот же запрос, что и ваш, только с использованием другого синтаксиса для одного из объединений, что имеет большое значение: ссылка a.maxa в dkcdТеперь условие соединения абсолютно корректно.

Как правильно заметил @Aaron Bertrand, вам, вероятно, следует подходить maxa с определенным псевдонимом, возможно a, в ORDER BY пункт.

• ORDER BY maxa все еще неоднозначен, не так ли? Также я был бы осторожен с датой «1 сентября 2011 года», она не будет работать с другими языковыми / региональными настройками.
• @Aaron: Согласен по поводу ORDER BY maxa, Благодарность. Что касается дат, я считаю, что именно так OP решил указать их в своей среде.
• «явные соединения … имеют приоритет над неявными» — не могли бы вы процитировать это, пожалуйста? например это определено в стандартах SQL или это особенность продукта? Спасибо.
• 1 @onedaywhen: Боюсь, это пока не более чем наблюдение с моей стороны. Меня несколько успокаивает тот факт, что я не первый, кто говорит здесь о приоритете объединений, но кроме этого, я был бы рад сам найти какое-либо официальное подтверждение.
• 1 В моем случае я забыл поставить пробелы при объединении строк для построения sql, поэтому ‘FROM dbo.table_a a’ + ‘INNER JOIN dbo.table_b b’ стало ‘FROM dbo.table_a aINNER JOIN dbo.table_b b’ , и он запутался и дал мне это сообщение об ошибке. Подробности, подробности, подробности.

Иногда эта ошибка возникает, когда вы неправильно используете схему (dbo) в запросе.

например, если вы напишете:

select dbo.prd.name from dbo.product prd 

вы получите ошибку.

В этой ситуации измените его на:

select prd.name from dbo.product prd 

• 1 Это довольно раздражает, и мне потребовалось слишком много времени, чтобы понять это. Спасибо. Самая неприятная часть — иногда он придирается к этому, но иногда проходит нормально.

если вы дали имя союзникам, измените его на настоящее имя

например

SELECT A.name,A.date FROM [LoginInfo].[dbo].[TableA] as A join [LoginInfo].[dbo].[TableA] as B on [LoginInfo].[dbo].[TableA].name=[LoginInfo].[dbo].[TableB].name; 

измените это на

SELECT A.name,A.date FROM [LoginInfo].[dbo].[TableA] as A join [LoginInfo].[dbo].[TableA] as B on A.name=B.name; 

• 1 Также, если вы создаете строку sql, следите за отсутствием конечных пробелов в конце строки. Он преобразовал мой псевдоним M в MINNER, когда он присоединился к следующей строке INNER JOIN ниже. Профилировщик SQL, показывающий выполненную строку, помог решить мою проблему. (Прокомментировано здесь, поскольку это связано с проблемой псевдонима v с фактическим именем)
• вау @Simon, спасибо, я даже не подумал об этом и бился головой о стену, пытаясь понять, почему мой запрос не работал, мне не хватало пробела в конце одного из символов возврата каретки!
• Это решило проблему, спасибо!

Я боролся с тем же сообщением об ошибке в SQL SERVER, так как у меня было несколько объединений, меняя порядок соединений решил это за меня.

В моем случае проблема оказалась в псевдониме, который я дал таблице. «oa» кажется неприемлемым для SQL Server.

У меня была такая же ошибка от JDBC. Все проверил, и мой запрос был в порядке. Оказалось, в предложении where у меня есть аргумент:

where s.some_column = ? 

И значение аргумента, которое я передавал, было нулевым. Это также дает ту же ошибку, которая вводит в заблуждение, потому что при поиске в Интернете вы обнаруживаете, что что-то не так со структурой запроса, но это не в моем случае. Просто подумал, что кто-то может столкнуться с той же проблемой

Что сработало для меня, так это изменить мое предложение WHERE на подзапрос SELECT

ИЗ:

 DELETE FROM CommentTag WHERE [dbo].CommentTag.NoteId = [dbo].FetchedTagTransferData.IssueId 

Кому:

 DELETE FROM CommentTag WHERE [dbo].CommentTag.NoteId = (SELECT NoteId FROM FetchedTagTransferData) 

Я новичок в SQL, но столкнулся с этой проблемой в ходе прохождения курса и обнаружил, что назначение запроса проекту специально помогло устранить ошибку, состоящую из нескольких частей. Например, созданный мной проект был CTU SQL Project, поэтому я убедился, что я начал свой скрипт с USE [CTU SQL Project] в качестве первой строки, как показано ниже.

USE [CTU SQL Project] SELECT Advisors.First_Name, Advisors.Last_Name...and so on. 

• 1 Когда вы говорите «проект», я предполагаю, что вы имеете в виду базу данных, а не проекцию. Оператор use просто изменяет базу данных, на которую вы накладываете запрос.
• Да, проект Charleh, как в базе данных, над которой я работал. Я не был уверен, что я делал не так с моей базой данных, но указание «использовать» и конкретную базу данных для области действия устранило мою ошибку.

Если эта ошибка возникает в UPDATE, дважды проверьте JOIN в таблице со столбцом / полем, вызывающим ошибку.

В моем случае это было из-за отсутствия JOIN сам, который генерировал ту же ошибку из-за неизвестного поля (как указал Андрей).

Вместо этого вы можете попробовать объединить такие таблицы, как,

select .... from dkcd right join a , b 

Это должно работать

SELECT DISTINCT phuongxa.maxa , quanhuyen.mahuyen , phuongxa.tenxa , quanhuyen.tenhuyen , ISNULL(dkcd.tong, 0) AS tongdkcd FROM phuongxa , quanhuyen LEFT OUTER JOIN ( SELECT khaosat.maxa , COUNT(*) AS tong FROM khaosat WHERE CONVERT(DATETIME, ngaylap, 103) BETWEEN 'Sep 1 2011' AND 'Sep 5 2011' GROUP BY khaosat.maxa ) AS dkcd ON dkcd.maxa = maxa WHERE phuongxa.maxa <> '99' AND LEFT(phuongxa.maxa, 2) = quanhuyen.mahuyen ORDER BY maxa; 

• Используйте сами имена таблиц вместо псевдонимов, если возникает проблема с привязкой к нескольким частям.

Моя ошибка заключалась в использовании поля, которого не было в таблице.

table1.field1 => не существует

table2.field1 => правильно

Исправьте имя вашей таблицы.

моя ошибка произошла из-за использования WITH

WITH RCTE AS ( SELECT... ) SELECT RCTE.Name, ... FROM RCTE INNER JOIN Customer ON RCTE.CustomerID = Customer.ID 

при использовании в сочетании с другими таблицами …

Вы забыли присоединиться к некоторым столам? В противном случае вам, вероятно, потребуется использовать псевдонимы.

Я также боролся с этой ошибкой и в конечном итоге использовал ту же стратегию, что и ответ. Я привожу свой ответ, чтобы подтвердить, что эта стратегия должна работать.

Вот пример, в котором я сначала выполняю одно внутреннее соединение между двумя таблицами, которые, как я знаю, получил данные, а затем два левых внешних соединения для таблиц, которые могут иметь соответствующие строки, которые могут быть пустыми. Вы смешиваете внутренние и внешние соединения, чтобы получить результаты с данными по таблицам, вместо того, чтобы использовать синтаксис по умолчанию, разделенный запятыми, между таблицами и пропускать строки в желаемом соединении.

use somedatabase go select o.operationid, o.operatingdate, p.pasid, p.name as patientname, o.operationalunitid, f.name as operasjonsprogram, o.theaterid as stueid, t.name as stuenavn, o.status as operasjonsstatus from operation o inner join patient p on o.operationid = p.operationid left outer join freshorganizationalunit f on f.freshorganizationalunitid = o.operationalunitid left outer join theater t on t.theaterid = o.theaterid where (p.Name like '%Male[0-9]%' or p.Name like '%KFemale [0-9]%') 

Во-первых: выполните внутренние соединения между таблицами, которые, как вы ожидаете, будут соответствовать данным. Вторая часть: продолжайте внешние соединения, чтобы попытаться получить данные из других таблиц, но это не отфильтрует ваш набор результатов, если внешнее соединение таблицы не имеет соответствующих данных или не соответствует условию, которое вы установили в предикате / условии on.

Эта ошибка также может быть вызвана просто отсутствием запятой. , между именами столбцов в операторе SELECT.

например:

SELECT MyCol1, MyCol2 MyCol3 FROM SomeTable; 

• Если SELECT MyCol1, MyCol2, MyCol3 FROM SomeTable; работает, то я не понимаю, как SELECT MyCol1, MyCol2 MyCol3 FROM SomeTable; могу дать вам любой ошибка, не говоря уже о той, что в заголовке этого вопроса. Если в вашем примере есть что-то, что бросается в глаза, в этом случае я предполагаю, что это не будет просто отсутствует запятая. Как вы думаете, можно ли придумать простой сценарий, воспроизводящий проблему, о которой вы говорите? Вот где я попытался просто опустить запятую, но это все равно сработало (= ошибки не было): dbfiddle.uk/…
• @AndriyM Единственное, о чем я могу думать, это то, что мой запрос, вероятно, был более сложным (возможно, с соединениями, извините, давным-давно). Но я уверен, что исправление для сообщения об ошибке, которое я получил (которое могло или не могло быть точно как в заголовке OP) нужно было просто поставить пропущенную запятую!