TERADATA: пока LOOP работает как SELECT, но не в моем SPROC

Question

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

Однако я могу нормально выполнить SELECT без цикла WHILE.Но когда я успешно создаю хранимую процедуру и запускаю ее, я получаю следующее сообщение:

OUTLETLOOPMG: Владелец, на которого ссылается пользователь, не имеет доступа SELECT к CORP_INVOICE_VIEWS.INVOICE_CORP.Ownrshp_ID

Что я не понимаю, так как выбор отлично работает без цикла.

Итак, два вопроса:

1. Что случилось с этой ошибкой?
2. Основываясь на логике, которую я описал в первом параграфе, мой цикл WHILE достигает этого?

Код:

CREATE  PROCEDURE OutletLoopMG()
BEGIN 
    DECLARE iVAR INT DEFAULT 52;
    DECLARE dVAR DATE DEFAULT current_date;

    --SET iVAR = 52;
    --SET dVAR = current_date;

    WHILE  iVAR > 0
    DO
    BEGIN
        INSERT INTO dlccc_cust_cntc_cntr_lab.OutletHolder
            SELECT 
                invcorp.OWNRSHP_ID, invcorp.BTLR_DLVR_PNT_NO,
                snap.btlr_branch_nm, snap.dlvr_pnt_nm,
                invcorp.inv_no, invcorp.inv_dt,
                cal.week_of_year, cal.year_of_calendar
            FROM
                corp_invoice_VIEWS.invoice_corp invcorp
            LEFT JOIN
                CHR_VIEWS.DPT_SNAPSHOT_SELECT snap ON invcorp.BTLR_DLVR_PNT_NO = snap.BTLR_DLVR_PNT_NO 
                                                   AND invcorp.OWNRSHP_ID = snap.OWNRSHP_ID 
            INNER JOIN
                sys_calendar.calendar cal ON invcorp.inv_dt = cal.calendar_date
            WHERE 
                1 = 1 
                AND invcorp.inv_dt = dVAR;
    END;    

    SET dVAR = (CAST(dVAR AS DATE) - 7);
    SET iVAR = (iVAR-1);

END WHILE;  
END;

Answer 1

Этот вопрос немного длинен, но благодаря недавнему редактированию он вернулся в начало очереди:

В процедурах есть три «роли», под которыми может быть обеспечена безопасность.назначено (на самом деле 4, но я доберусь до этого)

1. OWNER - это база данных / пользователь, под которой создается процедура.Если вы используете для процедуры настройки SQL SECURITY по умолчанию, то OWNER должен иметь доступ к объектам, используемым в процедуре WITH GRANT OPTION.Итак: GRANT SELECT ON corp_invoice_VIEWS TO <whatever database this proc is in> WITH GRANT OPTION вам нужно будет предоставить этот доступ для каждой базы данных / представления / таблицы, которые выбраны здесь в предложении FROM.

2. СОЗДАТЕЛЬ - Это вы, поскольку вы составляете процедуру.При использовании настроек SQL SECURITY по умолчанию для процедуры вам потребуется доступ к объектам, используемым в процедуре.Вы должны иметь такой доступ уже для того, чтобы запустить SELECT самостоятельно.Так что это все хорошо.

3. INVOKER - это пользователь, который выполнит / вызовет процедуру.С настройками SQL SECURITY по умолчанию для процедуры INVOKER просто необходимо иметь EXECUTE процедуру для процедуры.

Параметры SQL SECURITY по умолчанию для процедуры (которые могут быть переопределены при написании процедуры) - SQL SECURITY DEFINER.Это «четвертая» роль, о которой я упоминал выше.Определитель безопасности проверяет, что и CREATOR, и OWNER процедуры имеют доступ к объектам в процедуре при компиляции процедуры.Более того, при выполнении процедуры OWNER привилегии проверяются еще раз.Выдает ошибку во время компиляции, если вы и база данных, в которой находится эта процедура, не имеют доступа.Он выдаст ошибку во время выполнения, если OWNER (база данных, в которой находится процедура) также не имеет доступа.

Ваши варианты решения этой ошибки:

1. Предоставьте владельцу процедуры SELECT доступ к таблицам, представлениям или базам данных, содержащим эти таблицы / представления, с параметром GRANT, чтобы выполнялось значение по умолчанию для ОПРЕДЕЛИТЕЛЯ БЕЗОПАСНОСТИ SQL.Это более безопасный и менее изменчивый маршрут.

2. Измените sql security для процедуры на SQL SECURITY CREATOR, чтобы при компиляции проверялись только ваши учетные данные (создатель процедуры).выполнение.Это дешевое исправление, но оно понятно, если вам не хватает разрешений для изменения защиты базы данных, в которой вы работаете.

3. Измените защиту SQL в процедуре на SQL SECURITY INVOKER, чтобы тольколицо, выполняющее процедуру после ее компиляции, используется для проверки привилегий.Это означает, что выполняемый пользователь должен не только иметь доступ к процедуре EXECUTE PROCEDURE, но и иметь доступ SELECT к представлениям / таблицам, используемым внутри.Это, вероятно, более безопасный вариант, чем номер 2, но менее надежный, чем вариант 1 (где проверяются создатель и владелец).

Подробнее о процедуре обеспечения безопасности можно прочитать на сайте документации .