Тип PL / SQL не меняется при изменении таблицы - PullRequest
0 голосов
/ 11 сентября 2018

Я создал этот пакет с типом PL / SQL внутри в базе данных Oracle 11.2.0.3:

CREATE OR REPLACE PACKAGE "DBATCK"."PKG_TCK_MGMTCK" AS

...

TYPE TYPE_SHOW_USR
is table of DBATCK.VW_SHOW_USR%ROWTYPE;

...

END PKG_TCK_MGMTCK;
/

Oracle автоматически создает тип с именем

create or replace type SYS_PLSQL_342468_34_1 as object 
(
 "IDCODEAMB" NUMBER,
 "DESCRAMB" VARCHAR2(50 BYTE),
 "IDCODEAPP" VARCHAR2(7 BYTE),
 "DESCRAPP" VARCHAR2(50 BYTE)
); 

но если я изменю столбец DESCRAPP с varchar2(50) на varchar2(100) в таблице SHOW_USR и в представлении VW_TCK_USERS, то при перекомпиляции пакета PKG_TCK_MGMTCK тип PL / SQL не изменить.

Почему?


--TABLE
create table DBATCK.SHOW_USR 
(
 "IDCODEAMB" NUMBER,
 "DESCRAMB" VARCHAR2(50 BYTE),
 "IDCODEAPP" VARCHAR2(7 BYTE),
 "DESCRAPP" VARCHAR2(50 BYTE)
); 

--VIEW
create view DBATCK.VW_SHOW_USR as select * from DBATCK.SHOW_USR;

1 Ответ

0 голосов
/ 11 сентября 2018

Кажется, это ошибка при определении типа коллекции для представления, а не для таблицы.Изменение определения таблицы делает недействительным представление и спецификацию / тело пакета, как и ожидалось, но не типы 1 ;поэтому, когда представление и пакет неявно перекомпилируются при следующей ссылке, типы, похоже, упускаются из виду.

Перекомпиляция пакета или представления или даже явное повторное введение команды create or replace для спецификации и тела пакета некажется, что это имеет какой-либо эффект.

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

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

Вы не делаетехотя должно быть довольно жестоким.Хотя перекомпиляция представления не помогает, переопределение его на месте делает:

create or replace view VW_SHOW_USERS as select * from SHOW_USR;

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

Я создал демо-версию db <> fiddle , показывающую исходную проблему и различные неудачные попытки ее исправить, а затем переопределение вида.


1 Есликоллекция определяется непосредственно по таблице, а не по представлению, тогда тип также аннулируется alter table, поэтому он перекомпилируется с новым определением, и эта проблема не возникает.При использовании представления выглядит, что что-то упущено при оценке зависимостей.Может быть стоит подать запрос на обслуживание в Oracle, чтобы выяснить это.(Я только смог довести это поведение до 12cR2; возможно, кто-то может проверить, что происходит в 18?)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...