Подтвердить что ты не робот

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
4b9b3361

Ответ 1

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

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>

ТЛ; др

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

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


Обратное также верно. Если мы создадим таблицу без использования двойных кавычек...

create table PS_TBL_DEPARTMENT_DETAILS
( company_code VARCHAR2(255),
  company_name VARCHAR2(255),
  Cost_Center_Number VARCHAR2(255))
;

… Мы можем ссылаться на него и на его столбцы в любом случае, если нам захочется:

select * from ps_tbl_department_details

… или же

select * from PS_TBL_DEPARTMENT_DETAILS;

… или же

select * from PS_Tbl_Department_Details
where COMAPNY_CODE = 'ORCL'
and cost_center_number = '0980'

Ответ 2

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

Когда я выполнил "describe tablename", я не смог найти столбец, указанный в файле hbm отображения.

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

Ответ 3

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-стиль, и делал это постепенно, по одной таблице за раз. Кажется, это была плохая идея. Вместо этого, вероятно, лучше всего конвертировать все таблицы сразу или закомментировать таблицу и ее условия, в которых условия исходного запроса, чтобы сравнить с новым запросом ANSI, который вы пишете.

Ответ 4

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

Ответ 5

У вас есть столбец DEPARTEMENT_CODE в таблице PS_TBL_DEPARTMENT_DETAILS

Дополнительная информация о вашей ERROR

ORA-00904: строка: неверный идентификатор     Причина. Введенное имя столбца либо отсутствует, либо недействительно.     Действие: Введите допустимое имя столбца. Действительное имя столбца должно начинаться с письмо,     быть меньше или равно 30 символам и состоять только из буквенно-цифровые символы и     специальные символы $, _ и #.     Если он содержит другие символы, то он должен быть заключен в d double кавычки.     Это не может быть зарезервированное слово.

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

Select * from emp_table where emp_id=123;

вместо вышеуказанного используйте это:

Select * from emp_table where emp_id='123';

Ответ 9

У меня была эта ошибка при попытке сохранить сущность через JPA.

Это было потому, что у меня был столбец с аннотацией @JoinColumn котором не было аннотации @ManyToOne.

Добавление @ManyToOne проблему.

Ответ 10

Убедитесь, что нет/после ваших заявлений DDL.