Значение столбца курсора случайно усекается?

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

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

Это курсор:

CURSOR cur_clients IS
    SELECT DISTINCT p.PROPOSAL_ID, rop.client_id, c.FORENAME, c.INITIAL1, c.SURNAME, concat(c.FORENAME,c.SURNAME),
      c.DATE_OF_BIRTH, c.SEX, a.ADDRESS_LINE1, a.ADDRESS_LINE2, a.ADDRESS_LINE3, a.ADDRESS_LINE4, '', a.POSTCODE, c.PPSN_NO, swr.scv_code
      FROM proposal p, roleonproposal rop, client c, address a, scv_wn_roles swr
      WHERE p.proposal_id = p_proposal_id
      AND p.proposal_id = rop.proposal_id
      AND rop.ROLE_ID <> v_Role
      AND rop.CLIENT_ID = c.CLIENT_ID
      AND c.CLIENT_ID = a.CLIENT_ID
      AND p.PROPOSAL_ID = a.PROPOSAL_ID
      AND rop.role_id = swr.id
      AND p.company_id = swr.company_id;

Усекается столбец swr.scv_code из таблицы scv_wn_roles. Возможные значения: ('WL1','WL2','WG','WB','WD','WP','WT','WE'), но иногда вставляется только буква W.

Затем я перебираю курсор следующим образом:

FOR c_client IN cur_clients LOOP

И таблица, где роль вставляется как W, находится здесь:

INSERT INTO scv_policy_client_lookup spc
   (spc.policy_number, spc.system_client_id, spc.qsclient_id, spc.role_id)
VALUES
   (c_client.proposal_id, c_client.client_id, v_QS_id, c_client.scv_code);

Структура двух таблиц следующая:

create table SCV_WN_ROLES
(
  ID              NUMBER(10) not null,
  REF_DESCRIPTION VARCHAR2(50),
  COMPANY_ID      NUMBER not null,
  SCV_CODE        CHAR(3)
);

И,

create table SCV_POLICY_CLIENT_LOOKUP
(
  POLICY_NUMBER    VARCHAR2(42) not null,
  SYSTEM_CLIENT_ID VARCHAR2(51) not null,
  QSCLIENT_ID      NUMBER(38,10) not null,
  ROLE_ID          VARCHAR2(4) not null,
  COUNTRY_IND      VARCHAR2(1) default 'R'
)

Столбец swr.scv_code вставляется в другие таблицы внутри хранимой процедуры и в них работает нормально, только эта таблица поиска.

Я попытался переместить значение курсора c_client.scv_code в локальную переменную VARCHAR2(3), а затем записать это в таблицу поиска, но это тоже не всегда работает.

Мы используем Oracle 11g, если это имеет значение.

Кто-нибудь заметил что-нибудь подозрительное?

Спасибо за помощь, mcquaim


person mcquaim    schedule 26.04.2013    source источник
comment
Вы абсолютно уверены, что в вашей таблице есть только эти 8 значений роли? Когда вы использовали локальную переменную, отображали ли вы ее для проверки, и если да, отображалось ли это W или более длинное значение? (Почему вы смешиваете CHAR(3), VARCHAR(3) и VARCHAR(4) для одного и того же значения?) Мне интересно, есть ли у вас неверные данные, или что-то еще обрезает их позже - если вы выбираете значение обратно из таблицы в том же проце, показывает ли это W, или вы можете наблюдать это только после завершения процесса?   -  person Alex Poole    schedule 26.04.2013
comment
Привет Алекс, спасибо за ответ. В таблице 16 ролей, но для разных компаний (1 и 4), но только те 8, которые имеют отношение к моему тесту. Таблица ролей — это существующая таблица, которая была определена как CHAR(3), поэтому я не хотел ее менять, если в этом нет необходимости. Как вы думаете, это может быть моя проблема? Если я запускаю запрос курсора вручную, я ВСЕГДА получаю правильные значения роли, никогда не усекая. Если я вручную запускаю Oracle SP, он всегда работал, кроме 1 раза. Я пробовал отлаживать в PLSQL, и у него никогда не было неправильной роли, даже с моей локальной переменной.   -  person mcquaim    schedule 26.04.2013
comment
это происходит только для значений scv_code, которые имеют только два символа???   -  person psaraj12    schedule 26.04.2013
comment
Нет, это происходит с WL1, WL2 или некоторыми значениями из двух символов, такими как WP или WE.   -  person mcquaim    schedule 26.04.2013
comment
Обратите внимание, что CHAR(3) дополняет пробелами все, что короче. Это означает, что ваши значения будут ('WL1','WL2','WG','WB','WD','WP','WT','WE'). Трудно увидеть с пропорциональным шрифтом, но после любого из двух кодов символов есть пробел.   -  person Brian    schedule 28.04.2013
comment
Привет Брайан! Но даже с пробелом CHAR(3) все равно должен хорошо вписываться в VARCHAR2(4) без усечения? Мне кажется странным, что иногда это работает, а иногда нет, непоследовательно.   -  person mcquaim    schedule 28.04.2013
comment
У кого-нибудь есть идеи? Я думаю, что мой следующий подход будет состоять в том, чтобы изменить определение таблицы так, чтобы оно было все тем же VARCHAR2 (4), но не уверен, что это будет решением TBH.   -  person mcquaim    schedule 29.04.2013


Ответы (1)


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

У нас есть ночное пакетное задание, которое выполняется на IBM Datastage и Qualitystage и назначает уникальные идентификаторы клиентов QS. Плохой дизайн этого пакетного задания означал, что оно считывало все содержимое этой таблицы во временный набор данных, а затем снова записывало все это с новыми идентификаторами QS.

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

Вышеупомянутая вставка на самом деле хороша, но проблемы вызывает ночная работа Datastage.

Еще раз спасибо всем, кто заглянул.

person mcquaim    schedule 30.04.2013