Всех с наступающими!

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

В.Казимирчик.

There are «standard» methods for determining whether an application or subroutine is running in any specified environment:
- For OFS the common variable GTSACTIVE will be set.
- For GUI the common variable TTYPE will contain the text GUI.
- For Browser the common variable GTSACTIVE will be set.

Получается, что для того, чтобы не портить жизнь своим коллегам, работающим под Desktop, достаточно написать:

IF NOT(INDEX(TTYPE,'GUI',1)) THEN DEBUG

Для того, чтобы экранировать DEBUG для пользователей Browser и OFS-обработки, понадобится следующая конструкция:

$INSERT I_GTS.COMMON
IF NOT(GTSACTIVE) THEN DEBUG

Можно заранее заготовить кусок кода, объединив оба примера, и вставлять его вместо DEBUG:

$INSERT I_GTS.COMMON
IF NOT(INDEX(TTYPE,'GUI',1) OR GTSACTIVE) THEN DEBUG

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

P.S. Спасибо моему коллеге SIA за идею.

Программное использование настроек EB.ALTERNATE.KEY

Если альтеранитвынй индекс был заведен с настройками   3. 1 CONCAT.TYPE.... SYSTEM
   4. 1 ACCESS.METHOD.. READто Т24 автоматически создаст concat-файл. Получить доступ к этому файлу из пользовательского интерфейса нельзя, зато с такой таблицей можно работать программно, т.е этот файл можно открыть и прочитать его содержимое. В качестве имени создаваемого приложения используется склейка <ИМЯ ПРИЛОЖЕНИЯ>.<ИМЯ ПОЛЯ>. В качестве ID записей этого приложения будут использоваться значения поля, по которому строится альтернативный индекс. В самой записи буду содержаться ID записей основного приложений.

Например, пусть есть вот такая настройка:    APPLICATION....... ACCOUNT
---------------------------------------
   1 ALT.KEY.MAX.LENGTH 35
   2. 1 ALT.KEY.FIELD.. OUR.EXT.ACCT.NO
   3. 1 CONCAT.TYPE.... SYSTEM
   4. 1 ACCESS.METHOD.. READ
   5. 1 UNIQUE......... NONE
При этом будет создан файл F.ACCOUNT.OUR.EXT.ACCT.NO

Содержимое одной из записей этого файла:jsh pmb ~ -->JED F.ACCOUNT.OUR.EXT.ACCT.NO 123-456-789
 
File F.ACCOUNT.OUR.EXT.ACCT.NO , Record '123-456-78 Insert 12:25:58
Command->
0001 KZ0010001*19364
-------------------------------- End Of Record --------------------------------«19364» &#151 это ID записи в таблице ACCOUNT, в которой поле 111.OUR.EXT.ACCT.NO равно «123-456-789»:jsh pmb ~ -->LIST FBNK.ACCOUNT WITH OUR.EXT.ACCT.NO EQ "123-456-789" OUR.EXT.ACCT.NO
LIST FBNK.ACCOUNT WITH OUR.EXT.ACCT.NO EQ "123-456-789" OUR.EXT.ACCT.NO PAGE 1 11:06:51 21 APR 2009
 
@ID............. OUR.EXT.ACCT.NO....................
 
           19364 123-456-789
 
 1 Records Listed
 
jsh pmb ~ -->Обратите внимание на префикс с кодом компании.

В зависимости от настроек поля 5.x UNIQUE в EB.ALTERNATE.KEY запись concat-файла может содержать один или несколько ID из основного приложения.

Особенности настройки и использования

Если настройки EAK были сделаны уже после того, как в основном приложении были созданы записи, то необходимо помнить, что информация по ранее заведенным данным не попадет в concat-файл после авторизации записи в EAK. Для построения альтернативного индекса по имеющимся записям, нужно зайти в каждую из имеющихся записей в основном приложении, внести изменения в поле на которое настроек EAK и авторизовать запись. Только после этого данные попадут в concat-файл. Просто переавторизовать запись будет недостаточно.

Ручные изменения в записях это не выход, проще будет создать свою build рутину, и указать ее в поле 7.x BUILD.ROUTINE, Эта рутина не имеет входных и выходных параметров. Она должна быть прописана в приложении PGM.FILE, при этом поле 1.TYPE должно быть задано как «S», а в поле 8.x APPL.FOR.SUBR должно быть указано имя основной таблицы. Рутина выполнится, если запустить соответствующую запись в EAK с функцией V(erify). Для каждого альтернативного индекса должна быть написана своя рутина.

Важной особенностью использования EAK является то, что анализ введенного значения, не является ли оно альтернативным индексом, и замена его на ID из основного файл, происходит до выполнения основного функционала по открытию записи. Поясню на примере из жизни: в рамках внедрения мигрировали клиентов в Т24, на клиенте (CUSTOMER) завели поле, в котором хранили ID из старой системы и настроили на это поле альтернативный индекс. Важно, что этот индекс числовой &#151 6-тизначный, Т24 по-умолчанию формирует так же 6-тизначные ID в CUSTOMER. Таким образом получили ситуацию, при которой, теоретически, альтернативный индекс может совпадать с каким-нибудь реальным ID из Т24. Так и случилось: в списке неавторизованных записей осталось 43 записи в статусе IHLD, при попытке открыть любую запись из этого перечня на редактирование &#151 открываются другие авторизованные записи. Так происходило потому, что Т24 сначала интерпретировал 6 цифр как альтернативный индекс, находил такой индекс и вместо первоначальных 6-ти цифр подставлял ID другой записи.

Другой пример из реального внедрения. EAK был настроен на приложение FUNDS.TRANSFER на поле DEBIT.THEIR.REF. Когда начали тестироваться на большом количестве реальных входящих сообщений, в качестве DEBIT.THEIR.REF попадались разные значения, как 16-тизначные буквенно-цифровые комбинации, так и просто «1», «13», «237» и т.п. Ранее, до заведения настроек EAK, получить доступ к записи в FT, например FT0600300501, можно было как минимум 2-мя способами: введя полный ID, или ограничиться только «501». В случае с «включенным» EAK, при вводе «501» система находила соответствующий альтернативный индекс, и открывала на редактирование не FT0600300501, а какую-то другую запись.

Программно это можно сделать при помощи вызова функции SYSTEM(1029). Эта функция возвращает динамический массив, содержащий весь стек, включая все вызовы подпрограмм при помощи CALL и переходы GOSUB. Элементы стека разделены в этом массиве при помощи VM. В каждом элементе хранятся четыре атрибута разделенных SM. Рассмотрим их, и начнем сразу с четвертого, потому что в нем хранится имя «родительской» рутины, или имя текущей подпрограммы, если был переход по GOSUB, а именно этот параметра чаще всего и интересен при программном разборе стека вызовов. В первом атрибуте указывается глубина стека вызовов посредством CALL, второй атрибут &#151 глубина стека переходов по GOSUB. При последовательном вызове нескольких рутин, каждый вызов будет добавлять элемент в начало стека, в каждом элементе будет последовательно наращиваться значение в первом атрибуте. Если в рамках одной рутины выполнено несколько переходов по GOSUB, то каждый такой переход так же добавит новый элемент в начало стека. У этих элементов значение первого атрибута будет одинаковым, но будет последовательно наращиваться значение во втором атрибуте. Третий атрибут содержит номер строки «родительской» программы, в которой был вызов текущей рутины, либо номер строки текущей рутины, в которой был инициирован переход по GOSUB.

Рассмотрим небольшой пример: имеется программа TEST.CALL.STACK.PRG из нее вызывается рутина TEST.CALL.STACK.RTN.1, а из нее далее вызывается рутина TEST.CALL.STACK.RTN.2. В последней рутине выполняется 3 перехода по GOSUB. Если после последнего перехода задать переменную Y.CALL.STACK какY.CALL.STACK = SYSTEM(1029)то ее содержимое будет примерно таким:Y.CALL.STACK<1,1> = '3\3\24\TEST.CALL.STACK.RTN.2'
Y.CALL.STACK<1,2> = '3\2\16\TEST.CALL.STACK.RTN.2&#39
Y.CALL.STACK<1,3> = '3\1\8\TEST.CALL.STACK.RTN.2'
Y.CALL.STACK<1,4> = '2\1\12\TEST.CALL.STACK.RTN.1'
Y.CALL.STACK<1,5> = '1\1\6\TEST.CALL.STACK.PRG'
Символом «\» представлен разделитель SM.

Существует еще один вариант программного получения стека вызовов &#151 при помощи функции OCONV:
Y.CALL.STACK = OCONV('','U0016')

Полученный результат гораздо менее информативен чем в предыдущем варианте &#151 функция возвращает только имена рутин, разделенные пробелами, при этом переходы по GOSUB никак не учитываются. Однако в большинстве случаев этого будет достаточно. Если в примере, который мы использовали выше применить способ получения стека через OCONV то результат будет такой:Y.CALL.STACK = 'TEST.CALL.STACK.RTN.2 TEST.CALL.STACK.RTN.1 TEST.CALL.STACK.PRG'

Есть еще один способ посмотреть содержимое стека вызова &#151 через отладчик. Этот способ может оказаться особенно полезным, когда система «сваливается» в DEBUG в неожиданном месте и нужно будет исследовать проблему или собрать необходимые данные для HelpDesk. В отладчике содержимое стека можно отобразить командой «j -g». Для нашего примера результат этой команды будет примерно таким:jBASE debugger->j -g
Line 0 , Source jmainfunction.b , Level 0
Source changed to /data/t24/test/bnk.run/ETC.BP/TEST.CALL.STACK.PRG
0006 CALL TEST.CALL.STACK.RTN.1
Source changed to /data/t24/test/bnk.run/ETC.BP/TEST.CALL.STACK.RTN.1
0012 CALL TEST.CALL.STACK.RTN.2
Source changed to /data/t24/test/bnk.run/ETC.BP/TEST.CALL.STACK.RTN.2
0008 GOSUB LABEL.1
0016 GOSUB LABEL.2
0024 GOSUB LABEL.3


Если использовать команду «j», то отобразиться только стек GOSUB:jBASE debugger->j
0008 GOSUB LABEL.1
0016 GOSUB LABEL.2
0024 GOSUB LABEL.3

Под Т24 результат работы команды будет несколько другой, вот, например, результат просмотра стека в валидационной рутине на версии в приложении SECTOR:jBASE debugger->j -g
Line 0 , Source jmainfunction.b , Level 0
Line 47 , Source EX
Line 262 , Source T.EX
Line 70 , Source RUN.APPLICATION
Line 138 , Source RUN.APPLICATION
Line 29 , Source EB.EXECUTE.APPLICATION
Line 69 , Source SECTOR
Line 37 , Source FIELD.MULTI.INPUT
Line 390 , Source T.FIELD.MULTI.INPUT
Line 1232 , Source T.FIELD.MULTI.INPUT
Line 85 , Source VERSION.VALIDATION
Line 70 , Source EB.CALL.API
Line 178 , Source EB.CALL.API
jBASE debugger->

Если мы откроем на просмотр таблицу CUSTOMER.ACCOUNT, то увидим примерно следующее:

На первый взгляд, похоже на обычное многозначное поле, но если мы посмотрим на содержимое файл из jBase, то увидим вот что:
File FBNK.CUSTOMER.ACCOUNT , Record '100115' Insert 17:23:42
Command->
0001 19208
0002 19216
0003 20273
0004 21512
0005 21733
-------------------------------- End Of Record --------------------------------

Т.е. фактически в файле, каждый элемент списка - это отдельное поле, а не значение многозначного поля. Следует иметь это в виду при программной обработке concat-файлов.

Меня время от времени спрашивали, есть ли список всех concat-файлов, и я отвечал, что такого списка нет. И правда, в документации эти файлы описываются редко, но в то же время они могут оказаться очень полезными в различных локальных разработках. Недавно я сообразил, как получить такой список, решение оказалось настолько простым и очевидным, что я удивляюсь, как не додумался до него раньше:
jsh pmb ~ -->SSELECT F.PGM.FILE WITH TYPE = "T"
 
231 Records selected
 
>SAVE-LIST CONCAT.FILES
231 record(s) saved to list 'CONCAT.FILES'
jsh pmb ~ -->

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

Кроме уже существующих файлов можно создавать и пользовательские. На небольшом примере, покажу, как это делается. Предположим, что у нас есть локальное приложение, одно из полей которого «привязано» к DE.I.HEADER. Для примера назовем эту таблицу - LOC.APPLICATION. Для привязки поля к другому приложению мы используем массив CHECKFILE, далее приведено описание только одного поля в LOC.APPLICATION:
Z += 1 ; F(Z) = "XX.IN.DEL.REF" ; N(Z) = "25.." ; T(Z) = "AA"
CHECKFILE(Z) = "DE.I.HEADER" : FM : DE.HDR.FROM.ADDRESS

Предположим, что мы создаем concat-файл, чтобы узнать какие записи из создаваемого нами приложения, буду привязаны к конкретным входящим сообщениям (они как раз и регистрируются в DE.I.HEADER) Назовем такой файл, например LOC.IN.DELIVERY.LINK. Тогда описание нашего поля в LOC.APPLICATION нужно дополнить заполнением массива CONCATFILE:
Z += 1 ; F(Z) = "XX.IN.DEL.REF" ; N(Z) = "25.." ; T(Z) = "AA"
CHECKFILE(Z) = "DE.I.HEADER" : FM : DE.HDR.FROM.ADDRESS
CONCATFILE(Z) = "AL":FM:"LOC.IN.DELIVERY.LINK"

Если смотреть описание массива CONCATFILE в I_RULES, то выясняется, что первое поле в элементе этого массива может принимать значения:

Во второе поле элемента массива CONCATFILE прописывается имя concat-файла, в нашем случае LOC.IN.DELIVERY.LINK.

Далее необходимо создать LOC.IN.DELIVERY.LINK, для этого используем шаблон TEMPLATE.T, а секцию DEFINE.PARAMETERS я приведу ниже целиком:
DEFINE.PARAMETERS:
MAT F = "" ; MAT N = "" ; MAT T = ""
MAT CHECKFILE = "" ; MAT CONCATFILE = ""
ID.CHECKFILE = "" ; ID.CONCATFILE = ""
 
ID.F = "DEL.REF"; ID.N = "25.1"; ID.T = "AA"
ID.CHECKFILE = "DE.I.HEADER" : FM : DE.HDR.MESSAGE.TYPE
 
F(1) = "XX.LOC.APP.ID"; N(1) = "20.1"
CHECKFILE(1) = "LOC.APPLICATION" : FM : 1
 
RETURNТ.к. в качестве @ID используются ID записей из DE.I.HEADER, то соответствующим образам задается переменная ID.CHECKFILE. Содержимое каждой записи это ID из LOC.APPLICATION, это обуславливает заполнение массива CHECKFILE.

Важное замечание: согласно рекомендациям компании Теменос при создании conact-файлов следует учитывать размер возможных записей в создаваемой таблице, если количество значений в записи будет составлять несколько сотен (около тысячи) то следует использовать другие методы, либо менять структуру создаваемого concat-файла, чтобы избежать потерь в производительности всей системы.

Сортировка

По умолчанию команда SELECT возвращает несортированный список. Чтобы получить отсортированный массив по какому-либо полю нужно воспользоваться опциями BY (для сортировки по возрастанию) или BY-DSND (для сортировки по убыванию) например:

SELECT FBNK.CUSTOMER BY SECTOR

SELECT FBNK.CUSTOMER BY-DSND TARGET

Для простой сортировки по ID существует команда SSELECT.

В том случае, если поле по которому производится сортировка многозначное, используется первое значение этого поля.

Если необходимо сортировать по значениям многозначного поля, то используются операторы BY-EXP и BY-EXP-DSND. Результирующий список будет состоять из элементов вида: <id записи>VM<позиция значения в многозначном поле>. Рассмотрим пример, имеем файл ACCT.ACTIVITY, в котором прописана различная информация по оборотам по счетам. В поле 5. TRANSACT.CODE хранится код транзакции и это многозначное поле. В тестовом файле у меня всего 102 записи:

jsh pmb ~ -->COUNT FBNK.ACCT.ACTIVITY
 
  102 Records counted
 
jsh pmb ~ -->

Если мы просто выполним SELECT и сохраним список, то получим файл:

KZT101000001-200601
KZT100050019-200601
KZT145040001-200601
20907-200601
KZT146000001-200601
EUR100010012-200601
KZT131005555-200601
. . .

Добавим сортировку по полю TRANSACT.CODE:

jsh pmb ~ -->SELECT FBNK.ACCT.ACTIVITY BY-EXP TRANSACT.CODE
 
  304 Records selected
 
>

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

18837-200601]1
19248-200601]1
20125-200601]1
EUR100010011-200601]1
KZT100010012-200601]1
KZT100030011-200601]1
KZT100030012-200601]1
USD100010012-200601]1
USD100030011-200601]1
USD100030012-200601]1
XAU100010012-200601]1
XAU100110012-200601]1
. . .

Символ «]» служит для обозначения VM.

Если мы воспользуемся командой LIST, то увидим вот такую картину:

jsh pmb ~ -->LIST FBNK.ACCT.ACTIVITY BY-EXP TRANSACT.CODE TRANSACT.CODE
 
@ID..........................    TRANSACT.CODE
 
                 18837-200601                2
                 19248-200601                2
                 20125-200601                2
          EUR100010011-200601                3
          KZT100010012-200601                3
          KZT100030011-200601                3
          KZT100030012-200601                3
          USD100010012-200601                3
          USD100030011-200601                3
          USD100030012-200601                3
          XAU100010012-200601                3
. . .

Мы получили массив, отсортированный по значениям поля TRANSACT.CODE.

В случае если поле является не просто многозначным, но и каждое значение содержит подзначения (sub-values) то для сортировки будет использоваться первое подзначение.

Для более сложного запроса:

SELECT FBNK.ACCT.ACTIVITY = '[200601' BY @ID BY-EXP DAY.NO BY-EXP-DSND TRANSACT.CODE

Мы получим на выходе 102 записи (т.е. общее число записей без учета сортировки), и сохраненный список будет для нас бесполезен т.к. в нем будут элементы вида:

18837-200601]1
19248-200601]1
20125-200601]1
. . .

Получается, что для программного использования SELECT такую сложную сортировку использовать проблематично. Однако если мы тот же сложный запрос используем для команды LIST, то мы получим вполне корректные результаты:

jsh pmb ~ -->LIST FBNK.ACCT.ACTIVITY = '[200601' BY @ID BY-EXP DAY.NO
BY-EXP-DSND TRANSACT.CODE DAY.NO TRANSACT.CODE
 
@ID...................   DAY.NO   TRANSACT.CODE
 
          18821-200601       02              52
          18821-200601       03             401
          18821-200601       03             507
          18821-200601       03             730
          18837-200601       02               2
          18837-200601       03              50
          18837-200601       04              52
          18837-200601       04              58
          18837-200601       04              85
          18837-200601       04             210
          18837-200601       04             213
          18837-200601       04             401
          18837-200601       04             402
          18837-200601       04             730
          18837-200601       04             952
          19208-200601       02             210
          19208-200601       03             213
. . .

В файле ACCT.ACTIVITY ID записи состоит из номера счета, года и месяца, например 10111-200807. Нашим запросом мы запросили все записи за 200601, отсортированные по @ID (в нашем случае это эквивалентно сортировке по номеру счета), далее идет сортировка по дате, и затем — обратная сортировка по коду транзакции.

LIST и COUNT

Ранее я уже использовал вместо SELECT команды COUNT и LIST.

Если нужно узнать количество записей удовлетворяющих условиям выборки, то нет необходимости выполнять SELECT из под jsh, достаточно использовать то же условие для команды COUNT:

jsh pmb ~ -->COUNT FBNK.CUSTOMER WITH SECTOR EQ "4000"
 
  17 Records counted
 
jsh pmb ~ -->

Обращаю внимание, что в случае использования опции BY-EXP или BY-EXP-DSND (сортировка по многозначным полям) результаты работы SELECT и COUNT будут отличаться:

jsh pmb ~ -->SELECT FBNK.ACCT.ACTIVITY BY-EXP TRANSACT.CODE
 
  304 Records selected
 
>

jsh pmb ~ -->COUNT FBNK.ACCT.ACTIVITY BY-EXP TRANSACT.CODE
 
  102 Records counted
 
jsh pmb ~ -->

LIST позволяет не только отобрать данные удовлетворяющие условию выборки, но и просмотреть их. Если просто заменить SELECT на LIST, то jBASE будет пролистывать записи целиком, но если после условия выборки перечислить интересующие нас поля, то будут отображены только они, в удобном табличном виде. Примеры я приводил выше.

Списки

Я уже писал, что команда SELECT выбирает не сами данные, а строит список, обычно состоящий из ID записей, при этом, когда эта команда выполняется в jsh, пользователь переходит в «режим работы со списком». jBASE отображает количество записей удовлетворяющих условию выборки и также, меняется системное приглашение операционной системы.jsh pmb ~ -->SELECT FBNK.CUSTOMER WITH RESIDENCE EQ "US"
 
  5 Records selected
 
>

Мы можем сохранить список при помощи команды SAVE-LIST <ИМЯ СПИСКА>, список будет сохранен файле с именем <ИМЯ СПИСКА> в каталоге, прописанном в системной переменной окружения JBCLISTFILE. В случае T24 это обычно каталог bnk.run/&SAVEDLISTS&. После сохранения пользователь выходит из «режима работы со списком» и возвращается в обычный jsh:jsh pmb ~ -->SELECT FBNK.CUSTOMER WITH RESIDENCE EQ "US"
 
  5 Records selected
 
>SAVE-LIST US.RESIDENTS
5 record(s) saved to list 'US.RESIDENTS'
jsh pmb ~ -->

Сохраненный список (файл) US.RESIDENTS будет выглядеть примерно так:1004
100115
1002
100176
1003
. . .

Числа — это ID записей в таблице CUSTOMER, которые соответствуют условию выборки, разделены они обычным переводом строки (0d0a — для Windows и 0a — для Unix).

Для того чтобы продолжить работу с сохраненным списком, можно воспользоваться командой GET-LIST <ИМЯ СПИСКА>:jsh pmb ~ -->GET-LIST US.RESIDENTS
 
  5 Records selected
 
>

Результат выполнения команды SELECT или открытие соответствующего ей, ранее сохраненного, списка для системы jBASE эквиваленты.

Так как сохраненный список представляет собой обычный текстовый файл, то он может быть подготовлен заранее любым удобным способом и помещен в каталог bnk.run/&SAVEDLISTS&. Для того чтобы воспользоваться таким списком достаточно будет знать имя файла.

Чтобы выйти из «режима работы со списком» без сохранения, можно воспользоваться командой CLEARSELECT.

Команды для работы со списками

Существуют 3 команды для манипуляции со списками, AND-LISTS, OR-LISTS и XOR-LISTS. Все эти команды работают с двумя и более сохраненными списками. AND-LISTS получает новый массив, который состоит из элементов, имеющихся в первом и во втором списке. OR-LISTS создает новый список из уникальных элементов обоих списков и общих элементов. По сути OR-LISTS склеивает списки. XOR-LISTS, команда обратная AND-LISTS, получает только те значения, которые есть в первом списке, но не встречаются во втором, и наоборот.

Небольшой пример, выберем сначала записи клиентов — резидентов США, а затем — резидентов Франции.jsh pmb ~ -->SELECT FBNK.CUSTOMER WITH RESIDENCE EQ "US"
 
  5 Records selected
 
>SAVE-LIST US.RESID
5 record(s) saved to list 'US.RESID'
jsh pmb ~ -->SELECT FBNK.CUSTOMER WITH RESIDENCE EQ "FR"
 
  1 Records selected
 
>SAVE-LIST FR.RESID
1 record(s) saved to list 'US.RESID'
jsh pmb ~ -->

После этого склеим US.RESID и FR.RESID при помощи команды OR-LISTS:jsh pmb ~ -->OR-LISTS US.RESID FR.RESID
 
  6 Records selected
 
>SAVE-LIST US.FR.RESID
6 record(s) saved to list 'US.FR.RESID'
jsh pmb ~ -->

Дополнительные возможности SELECT

Опция SAVING UNIQUE позволяет не просто отобрать нужные записи, а выделить только уникальные значения нужного нам поля. Например, чтобы узнать какие значения поля RESIDENCE встречаются в таблице CUSTOMER достаточно выполнить команду:jsh pmb ~ -->SELECT FBNK.CUSTOMER SAVING UNIQUE RESIDENCE
 
  8 Records selected
 
>SAVE-LIST RESID
8 record(s) saved to list 'RESID'
jsh pmb ~ -->

В полученном списке будут не ID из таблицы CUSTOMER, а перечислены все уникальные значения поля RESIDENCE, которые встречаются в приложении, у меня на базе это выглядит так:KZ
US
AN
PT
LV
GB
DE
FR

Вторая полезная опция — SAVING EVAL, позволяет модифицировать список используя строковые константы, значения полей записи, некоторые функции jBASE. Очень удобно ее применять для построения списков, которые используют в приложении DL.DEFINE.

Для примера сформируем такой список для выгрузки всех значений приложения SECTOR:jsh pmb ~ -->SELECT FBNK.SECTOR SAVING EVAL '"SECTOR>":@ID'
 
  11 Records selected
 
>SAVE-LIST DL.SECTOR
11 record(s) saved to list 'DL.SECTOR'
jsh pmb ~ -->

Файл DL.SECTOR будет выглядеть так:SECTOR>3000
SECTOR>6000
SECTOR>9000
SECTOR>7272
SECTOR>1000
SECTOR>7000
SECTOR>4000
SECTOR>5000
SECTOR>2000
SECTOR>8000
SECTOR>7373

Разберем параметр, который мы указали для опции EVAL — '"SECTOR>":@ID'
"SECTOR>" — это текстовая константа, «:» — операция конкатенации, @ID — поле записи. Весь параметр целиком был заключен в одинарные кавычки, а внутри, для обозначения текстовой константы, мы использовали двойные кавычки., Кавычки взаимозаменяемы, т.е. записать параметр как "'SECTOR>':@ID".

Таким образом, при помощи SELECT мы отобрали нужные нам записи, а применение EVAL позволо нам провести несложные манипуляции с отобранными данными «на лету».

Условие

Более распространенный вариант применения – SELECT с использованием условия выборки, например:
SELECT FBNK.CUSTOMER WITH SECTOR GT 1SELECT FBNK.CUSTOMER WITH RESIDENCE EQ US

Условие формируется следующим образом:

ИМЯ.ПОЛЯ ОПЕРАТОР ЗНАЧЕНИЕ

Вот практически все операторы, которые можно использовать: EQ(=) - равно, NE(<>, #) - неравно, GT(>) - больше, LT(<) - меньше, GE(=>,>=) - больше или равно, LE(<=, =<) - меньше или равно, LIKE - соответствует шаблону, UNLIKE - не соответствует шаблону.

Значение лучше всего задавать в двойных кавычках. Если значение задано без кавычек, то парсер запросов вначале попытается найти поле с таким именем в файле, и только если не находит, то использует это значение как строку или число заданное пользователем. Например:SELECT FBNK.CUSTOMER WITH RESIDENCE NE NATIONALITYSELECT FBNK.CUSTOMER WITH RESIDENCE NE "NATIONALITY"В первом случае отбираются записи у которых значения полей RESIDENCE и NATIONALITY
не равны между собой, во втором случае содержимое поля RESIDENCE сравнивается со строкой «NATIONALITY».

Несколько условий выборки можно комбинировать использую скобки и операторы AND и ORSELECT FBNK.CUSTOMER WITH (RESIDENCE = "US" AND NATIONALITY = "US") OR (RESIDENCE = "FR" AND NATIONALITY = "FR")

Метасимволы

При формировании условия выборки можно воспользоваться метасимволами «[» - игнорирование слева, «]» - игнорирование справа, «^» - любой символ. Эти метасимволы применяются совместно с оператором EQ или «=».

SELECT FBNK.CUSTOMER WITH MNEMONIC EQ "AT]"Команда выберет все записи, у которых поле MNEMONIC начинается с «AT».

SELECT FBNK.CUSTOMER WITH SHORT.NAME EQ "[US"Получим список записей, у которых поле SHORT.NAME заканчивается «US».

SELECT FBNK.CUSTOMER WITH MNEMONIC EQ "M^^^"Выберет записи, у которых поле MNEMONIC состоит из 4-х символов и начинается с «M».

SELECT FBNK.CUSTOMER WITH MNEMONIC EQ "N^^]"Отберутся записи, у которых поле MNEMONIC состоит из не менее 3-х символов и начинается с «N».

Если выборка делается только по ID то можно использовать сокращенный форму:SELECT F.DE.ADDRESS = "US0010001]"

Поиск по шаблону

В случае операторов LIKE и UNLIKE в качестве значения используются шаблоны двух видов. Первый, наиболее часто используемый, шаблон в котором три точки («…») означают любое количество любых символов, например:

SELECT FBNK.CUSTOMER WITH SHORT.NAME LIKE "...LTD..."Команда выберет все записи, у которых в поле SHORT.NAME встречается подстрока «LTD» в любом месте.

Второй тип шаблонов которые можно применять, это паттерны которые используются в функции MATCHES 

Если n=0 то допускается совпадение любого числа (0 и более) символов. Шаблоны можно комбинировать:
3N6A – соответствует строке состоящей из 3-х цифр и 6-ти букв;
2C'.'3A'-'0X – совпадет со строкой, которая начинается с 2-ух цифр или букв, затем присутствует символ «.», после него 3 буквы, далее следует символ «-», и заканчивается любым числом любых символов.
Рассмотрим несколько примеров:

SELECT FBNK.CUSTOMER WITH MNEMONIC LIKE "'M'3A"Будут найдены записи, в которых значение поля MNEMONIC начинается с «M» и состоит из 4 букв.

SELECT FBNK.CUSTOMER WITH POST.CODE LIKE "5N"Отберутся записи, в которых значение поля POST.CODE состоит из 5 цифр.

SELECT FBNK.CUSTOMER WITH ACCOUNT.OFFICER LIKE "3N0N"Получим список записей, в которых значение поля ACCOUNT.OFFICER состоит из 3 и более цифр.

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

Для исправления нужно отредактировать DICT файл для VOC, запись «@», первоначально эта запись будет выглядеть, как показано ниже:jsh pmb ~ -->JED DICT VOC @
File DICT VOC , Record '@' Insert 18:07:16
Command->
0001 PH
0002 NAME TYPE DESC ID.SUP
-------------------------------- End Of Record --------------------------------

Из второй строки нужно удалить «DESC»:*File DICT VOC , Record '@' Insert 18:08:06
Command-> FI
0001 PH
0002 NAME TYPE ID.SUP
-------------------------------- End Of Record --------------------------------