ORA-00904: недопустимый идентификатор

Я попытался написать следующий внутренний запрос соединения, используя базу данных Oracle:

 SELECT Employee.EMPLID as EmpID, 
        Employee.FIRST_NAME AS Name,
        Team.DEPARTMENT_CODE AS TeamID, 
        Team.Department_Name AS teamname
 FROM PS_TBL_EMPLOYEE_DETAILS Employee
 INNER JOIN PS_TBL_DEPARTMENT_DETAILS Team 
 ON Team.DEPARTMENT_CODE = Employee.DEPTID

это дает следующую ошибку:

 INNER JOIN PS_TBL_DEPARTMENT_DETAILS Team ON Team.DEPARTMENT_CODE = Employee.DEPTID
                                              *
ERROR at line 4:
ORA-00904: "TEAM"."DEPARTMENT_CODE": invalid identifier

DDL одной таблицы:

CREATE TABLE "HRMS"."PS_TBL_DEPARTMENT_DETAILS"
(
  "Company Code" VARCHAR2(255),
  "Company Name" VARCHAR2(255),
  "Sector_Code" VARCHAR2(255),
  "Sector_Name" VARCHAR2(255),
  "Business_Unit_Code" VARCHAR2(255),
  "Business_Unit_Name" VARCHAR2(255),
  "Department_Code" VARCHAR2(255),
  "Department_Name" VARCHAR2(255),
  "HR_ORG_ID" VARCHAR2(255),
  "HR_ORG_Name" VARCHAR2(255),
  "Cost_Center_Number" VARCHAR2(255),
  " " VARCHAR2(255)
)
SEGMENT CREATION IMMEDIATE PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS

9 ответов


ваша проблема в этих пагубных двойных кавычках.

SQL> CREATE TABLE "APC"."PS_TBL_DEPARTMENT_DETAILS"
  2  (
  3    "Company Code" VARCHAR2(255),
  4    "Company Name" VARCHAR2(255),
  5    "Sector_Code" VARCHAR2(255),
  6    "Sector_Name" VARCHAR2(255),
  7    "Business_Unit_Code" VARCHAR2(255),
  8    "Business_Unit_Name" VARCHAR2(255),
  9    "Department_Code" VARCHAR2(255),
 10    "Department_Name" VARCHAR2(255),
 11    "HR_ORG_ID" VARCHAR2(255),
 12    "HR_ORG_Name" VARCHAR2(255),
 13    "Cost_Center_Number" VARCHAR2(255),
 14    " " VARCHAR2(255)
 15  )
 16  /

Table created.

SQL>

Oracle SQL позволяет игнорировать случай имен объектов базы данных при условии, что мы либо создаем их с именами в верхнем регистре, либо без использования двойных кавычек. Если мы используем смешанный регистр или нижний регистр в скрипте и завернули идентификаторы в двойные кавычки, мы обречены на использование двойных кавычек и точного случая всякий раз, когда мы ссылаемся на объект или его атрибуты:

SQL> select count(*) from PS_TBL_DEPARTMENT_DETAILS
  2  where Department_Code = 'BAH'
  3  /
where Department_Code = 'BAH'
      *
ERROR at line 2:
ORA-00904: "DEPARTMENT_CODE": invalid identifier


SQL> select count(*) from PS_TBL_DEPARTMENT_DETAILS
  2  where "Department_Code" = 'BAH'
  3  /

  COUNT(*)
----------
         0

SQL>

tl; dr

Не используйте двойные кавычки в сценариях DDL

(Я знаю, что большинство сторонних генераторов кода делают, но они достаточно дисциплинированы, чтобы поместить все свои имена объектов в верхнем регистре.)


в моем случае эта ошибка произошла из-за отсутствия имени столбца в таблице.

когда я выполнил "describe tablename" , Я не смог найти столбец, указанный в файле сопоставления НВМ.

после изменения таблицы, он работал нормально.


DEPARTMENT_CODE не является столбцом, который существует в команде таблицы. Проверьте DDL таблицы, чтобы найти правильное имя столбца.


FYI, в этом случае причиной было найдено имя столбца смешанного случая в DDL для создания таблицы.

однако, если вы смешиваете "старый стиль" и ANSI присоединяется, вы можете получить то же сообщение об ошибке, даже если DDL был сделан правильно с именем таблицы в верхнем регистре. Это случилось со мной, и google отправил меня на эту страницу stackoverflow, поэтому я думал, что поделюсь, так как я был здесь.

--NO PROBLEM: ANSI syntax
SELECT A.EMPLID, B.FIRST_NAME, C.LAST_NAME
FROM PS_PERSON A
INNER JOIN PS_NAME_PWD_VW B ON B.EMPLID = A.EMPLID
INNER JOIN PS_HCR_PERSON_NM_I C ON C.EMPLID = A.EMPLID
WHERE 
    LENGTH(A.EMPLID) = 9
    AND LENGTH(B.LAST_NAME) > 5
    AND LENGTH(C.LAST_NAME) > 5
ORDER BY 1, 2, 3
/

--NO PROBLEM: OLD STYLE/deprecated/traditional oracle proprietary join syntax
SELECT A.EMPLID, B.FIRST_NAME, C.LAST_NAME
FROM PS_PERSON A
, PS_NAME_PWD_VW B 
, PS_HCR_PERSON_NM_I C 
WHERE 
    B.EMPLID = A.EMPLID
    and C.EMPLID = A.EMPLID
    and LENGTH(A.EMPLID) = 9
    AND LENGTH(B.LAST_NAME) > 5
    AND LENGTH(C.LAST_NAME) > 5
ORDER BY 1, 2, 3
/

два оператора SQL выше эквивалентны и не производят ошибка.

когда вы пытаетесь смешать их, вам может повезти, или вы можете получить Oracle имеет ошибку ORA-00904.

--LUCKY: mixed syntax (ANSI joins appear before OLD STYLE)
SELECT A.EMPLID, B.FIRST_NAME, C.LAST_NAME
FROM 
    PS_PERSON A
    inner join PS_HCR_PERSON_NM_I C on C.EMPLID = A.EMPLID
    , PS_NAME_PWD_VW B
WHERE 
    B.EMPLID = A.EMPLID
    and LENGTH(A.EMPLID) = 9
    AND LENGTH(B.FIRST_NAME) > 5
    AND LENGTH(C.LAST_NAME) > 5
/

--PROBLEM: mixed syntax (OLD STYLE joins appear before ANSI)
--http://sqlfascination.com/2013/08/17/oracle-ansi-vs-old-style-joins/
SELECT A.EMPLID, B.FIRST_NAME, C.LAST_NAME
FROM 
    PS_PERSON A
    , PS_NAME_PWD_VW B
    inner join PS_HCR_PERSON_NM_I C on C.EMPLID = A.EMPLID
WHERE 
    B.EMPLID = A.EMPLID
    and LENGTH(A.EMPLID) = 9
    AND LENGTH(B.FIRST_NAME) > 5
    AND LENGTH(C.LAST_NAME) > 5
/

и бесполезное сообщение об ошибке, которое на самом деле не описывает проблему вообще:

>[Error] Script lines: 1-12 -------------------------
ORA-00904: "A"."EMPLID": invalid identifier  Script line 6, statement line 6,
column 51 

я смог найти некоторые исследования по этому вопросу в следующем блоге:

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


вы уверены, что у вас есть столбец DEPARTEMENT_CODE в таблице PS_TBL_DEPARTMENT_DETAILS


У меня было такое же исключение в JPA 2 с помощью Eclipse link. У меня был @embedded класс с отношением один к одному с сущностью. По ошибке, во встроенном классе у меня также была аннотация @Table ("трейдер"). Когда БД была создана JPA из сущностей, она также создала table TRADER (что было неправильно, поскольку сущность Trader была встроена в основную сущность), и существование этой таблицы вызывало вышеуказанное исключение каждый раз, когда я пытался сохранить свою сущность. После удаления за столом трейдера это исключение не устраивало.


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

для запросов к таблицам необходимо предоставить разрешение SELECT.
Для запросов к другим типам объектов (например, хранимым процедурам) необходимо предоставить разрешение EXECUTE.


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

Select * from emp_table where emp_id=123;

вместо этого использовать:

Select * from emp_table where emp_id='123';

убедитесь, что нет / после ваших операторов DDL.