Проблемы с оператором RPG Distinct and Join SQL - PullRequest
Новая
       75

Проблемы с оператором RPG Distinct and Join SQL

0 голосов
/ 03 октября 2019

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

SELECT DISTINCT 
    OrdItem                                            
FROM
    OrdMst 
INNER JOIN 
    ItmMst ON OrdMst.OrdItem = ItmMst.Item              
WHERE 
    OrdMst.ID = 'MR' 
    AND OrdMst.TYPE = 'F' 
    AND ItmMst.ItmType IN ('1', '2') 
ORDER BY 
    OrdMst.OrdItem;

Ответы [ 2 ]

2 голосов
/ 04 октября 2019

Я не вижу RPG ..

Если вы используете опубликованный оператор как часть оператора DECLARE CURSOR в RPG, то есть дополнительные предложения, которые управляют поведением курсора.

syntax diagram

Из документации
ASENSITIVE (по умолчанию)
Указывает, что курсор может вести себя какSENSITIVE или INSENSITIVE в зависимости от того, как оптимизируется оператор выбора.

SENSITIVE
Указывает, что изменения, внесенные в базу данных после открытия курсора, отображаются в таблице результатов. Курсор имеет некоторый уровень чувствительности к любым обновлениям или удалениям, внесенным в строки, лежащие в его таблице результатов после открытия курсора. Курсор всегда чувствителен к позиционированным обновлениям или удаляется с использованием одного и того же курсора. Кроме того, курсор может иметь чувствительность к изменениям, внесенным вне этого курсора. Если менеджер базы данных не может сделать изменения видимыми для курсора, то возвращается ошибка. Менеджер баз данных не может сделать изменения видимыми для курсора, когда курсор неявно становится доступным только для чтения. (См. Таблицу результатов курсора.) Если указан SENSITIVE, инструкция SELECT не может содержать ссылку на таблицу изменений данных.

INSENSITIVE
Указывает, что после открытия курсора он не будет чувствителен к вставкам, обновлениям или удалениям, выполняемым этой или любой другой группой активации. Если указан INSENSITIVE, курсор доступен только для чтения, и при его открытии создается временный результат. Кроме того, оператор SELECT не может содержать предложение UPDATE, и приложение должно разрешать копирование данных (ALWCPYDTA (* OPTIMIZE) или ALWCPYDTA (* YES)).

1 голос
/ 03 октября 2019

Лучше рассматривать любой отдельный оператор базы данных как мгновенное действие. База данных собирает все результаты и дает вам курсор, чтобы вы могли перебирать эти результаты (например, см. Раздел выбора здесь ). В postgres (и я бы предположил по умолчанию в другом месте) набор результатов не мутирует вместе с базой данных. DB2 пользователи должны видеть ответ от @Charles (ниже), поскольку DB2, очевидно, поддерживает мутирующие результаты.

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

Обычно мы не ожидаем / не хотим, чтобы база данных работала иначе. В качестве простого примера, представьте, что вы работаете с записями. Вы выбираете записи и порядок по last_modified. Вы что-то делаете с записью и обновляете last_modified. Если набор записей будет видоизменен, операция никогда не завершится, поскольку вы продолжаете прикреплять то, что вы изменили, в конце набора записей.

То, что вы пытаетесь достичь, не работает, потому что набор записей не работаетмутирует? Вам лучше спросить, как достичь этой цели в свете неизменной базы данных (мы называем это XY проблема ).

...