Получение набора записей из SQL на Ibm I - PullRequest
Новая
       26

Получение набора записей из SQL на Ibm I

0 голосов
/ 02 июля 2018

Итак, я пытаюсь модернизировать код на моем IBM i, и я думаю о подфайлах и файлах печати. ​​

Исключая собственные операции ввода-вывода, я могу придумать три способа наполнения моих данных с использованием встроенного SQL.

  1. Метод курсорной выборки
  2. Структура данных MultiOccurance для количества записей на одной странице
  3. Гораздо большая структура данных MultiOccurance, содержащая несколько страниц данных.

Какой метод наилучшей практики? Есть мнения?

Ответы [ 2 ]

0 голосов
/ 03 июля 2018

Я никогда не копировал подфайл с массивом, хотя, полагаю, это было бы полезно, если бы у вас было более 9999 записей. Вместо этого я всегда просто читал из курсора. На самом деле смешивание SQL и процедур делает заполнение подфайла чрезвычайно простым. Вы даже можете использовать выборку из нескольких записей, если это имеет смысл для вас. Вот простой пример (выборка одной записи): 

dcl-proc LoadSubfile;
  dcl-pi *n;
    keyFields       Type;
  end-pi;

  dcl-ds sflin        LikeRec(sfl: *Input) Inz;

  ClearSubfile();
  OpenCursor(keyFields);
  dow FetchCursor(record);
    eval-corr sflin = record;
    PopulateHidden(sflin);
    rrn += 1;
    write sfl sflin;
  enddo;
  CloseCursor();
  rrnMax = rrn;
end-proc;

Здесь есть некоторые вещи, которые не определены, например, FetchCursor() возвращает Indicator = * On, если возвращается запись. и PopulateHidden() заполняет скрытые поля в записи подфайла. Я использую скрытый в редактируемом подфайле для хранения исходных значений для полей, которые могут быть изменены. Я определяю поля подфайла так же, как поля записи, так что я могу сделать eval-corr, чтобы получить их в структуру данных ввода-вывода. Я также проверю переполнение подфайла rrn, если считаю, что в базе данных может быть более 9999 записей. Затем я выбрасываю сообщение subfile full с указаниями для фильтрации набора записей.

Некоторые другие вещи, о которых вы не спрашивали, но я расскажу вам, поскольку вы спрашивали о передовых методах. Если для этого нет причины, я использую SFLCLR для очистки подфайла и обычно загружаю весь подфайл за один раз, если не подозреваю, что будут тысячи записей. Многие из старых оптимизаций, таких как SFLNXTCHG и загрузка по одной странице за раз, были введены в действие, потому что связь была медленной. Не столько связь по протоколу twinax, сколько контроллер рабочей станции ASCII или удаленные рабочие станции, которые часто находились на другой стороне линии связи, намного медленнее, чем twinax. Это больше не правда. Я склонен избегать тех старых хаков, предназначенных для сохранения пропускной способности, потому что они только усложняют код. Запишите все сразу, а при обработке прочитайте весь подфайл с циклом for.

Кроме того, в будущем эти вопросы должны быть на Проверка кода , если у вас есть рабочий код, для которого вы хотите узнать о передовой практике, или, возможно, Разработка программного обеспечения , если вы больше интересуются теоретическими ответами. Переполнение стека больше для ответа на конкретные объективные вопросы.

0 голосов
/ 02 июля 2018

Возможно, не по теме, поскольку "в первую очередь основано на мнении"

Но массив DS .... чем больше, тем лучше ...

...