Alio написал(а):
-------------------------------------------------------
> А. Роман написал(а):
> --------------------------------------------------

> > 2. Импортировать записи (с указанием ТВП, ФЛК,
> > автоввода, актуализации, импорта со слиянием,
> > фильтрами).
> Не понял... Вы последнюю версию клиентского
> Администратора видели?

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

Все клиентские АРМы.

Реализована возможность сохранения НОВЫХ документов под номерами физически удаленных записей (т.е. в "дырках")

Данная возможность действует, если в секции [MAIN] профиля пользователя (irbisc.ini irbisb.in irbisp.ini irbisk.ini) установлен параметр

REUSE_PHYS_DEL=1

По умолчанию значение 0, т.е. "дырки" не заполняются.

Использовать данную возможность настоятельно рекомендуем тем, кого "смущает" наличие физ.удаленных записей, и кто в связи с этим применяет режим в АРМе Администратор РЕОРГАНИЗОВАТЬ ФАЙЛ ДОКУМЕНТОВ С ИСКЛЮЧЕНИЕМ УДАЛЕННЫХ ДОКУМЕНТОВ (который, в свою очередь, связан с тяжелыми последствиями - необходимостью СОЗДАВАТЬ СЛОВАРЬ ЗАНОВО ПОЛНОСТЬЮ)



Редактировано 1 раз. Последний раз 23.08.2023 15:53 пользователем Alio.

При отправки письма формата через АРМ каталогизатор не хватает возможности вставки формата в тело письма. сейчас файл прикрепляется как вложенный.

Государственная универсальная научная библиотека Красноярского края, Ассоциация ЭБНИТ

GLUKa написал(а):
-------------------------------------------------------
> При отправки письма формата через АРМ
> каталогизатор не хватает возможности вставки
> формата в тело письма. сейчас файл прикрепляется

О каком режиме идет речь?

> как вложенный.

речь о режиме через кнопку печать. там в новых версиях появилась возможность отослать результат печати на email


Alio написал(а):
-------------------------------------------------------
> GLUKa написал(а):
> --------------------------------------------------
> -----
> > При отправки письма формата через АРМ
> > каталогизатор не хватает возможности вставки
> > формата в тело письма. сейчас файл
> прикрепляется
>
> О каком режиме идет речь?
>
> > как вложенный.

Государственная универсальная научная библиотека Красноярского края, Ассоциация ЭБНИТ

GLUKa написал(а):
-------------------------------------------------------
> речь о режиме через кнопку печать. там в новых
> версиях появилась возможность отослать результат
> печати на email
>
и именно там работает параметр MailOption, который позволяет включать в тело письма результат печати в формате HTML.
Если это не так, значит Вы применяете не последнюю версию irbisbat_plus.exe

irbisbat_plus.exe из поставки а в двух релизах к 22 версии его не было

в релизе написано что MAILOPTION параметр для АРм Книговыдача
АРМ Книговыдача
1. Введен параметр в секцию [MAIN] irbisb.ini
MAILOPTION=

Государственная универсальная научная библиотека Красноярского края, Ассоциация ЭБНИТ



Редактировано 1 раз. Последний раз 29.08.2023 14:08 пользователем GLUKa.

GLUKa написал(а):
-------------------------------------------------------
> irbisbat_plus.exe из поставки а в двух релизах к
> 22 версии его не было
>
> в релизе написано что MAILOPTION параметр для АРм
> Книговыдача
> АРМ Книговыдача
> 1. Введен параметр в секцию irbisb.ini
> MAILOPTION=
Он же работает и в irbisc.ini

я пробовала его применять но в каталогизаторе но все равно файл прикрепляется. попробую снова

Alio написал(а):
-------------------------------------------------------
> GLUKa написал(а):
> --------------------------------------------------
> -----
> > irbisbat_plus.exe из поставки а в двух релизах
> к
> > 22 версии его не было
> >
> > в релизе написано что MAILOPTION параметр для
> АРм
> > Книговыдача
> > АРМ Книговыдача
> > 1. Введен параметр в секцию irbisb.ini
> > MAILOPTION=
> Он же работает и в irbisc.ini

Государственная универсальная научная библиотека Красноярского края, Ассоциация ЭБНИТ

Во втором апдейте к версии 2022 в ФЛК записи для RDR добавили непреодолимый контроль для защиты 907 поля от ручной корректировки

if v907<>ref(mfn,v907) then '1Нельзя корректировать 907 поле!' else…

В результате невозможно восстановить логически удаленную запись. Точнее восстановить-то, конечно, можно, а вот сохранить – нет. Потому что ref к логически удаленной записи не возвращает ничего.
К сожалению, обойти эту ситуацию никак нельзя. &uf('N1,v907') здесь тоже не помогает, поскольку обращается все-таки к самой ранней предыдущей копии. В то же время проверять статус записи тоже смысла нет – максимум что можно сделать если &uf('+6')='0' это просто отменить проверку вовсе, ведь даже если в 907 поле вносились изменения, мы этого никак не узнаем из-за «зазора» между фактическими данными в БД (к которым обратиться форматер не может) и «полкой» куда программа поместила эти данные при восстановлении.
Может быть имеет смысл доработать &uf('4') расширив перечень вариантов первого аргумента за счет «0»?
То есть &uf('40,format') расформатировало бы именно активную запись, повторно обращаясь к базе. Ну то есть тот же ref(mfn,fmt), только игнорирующий статус записи в БД.

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

Web-ИРБИС64

В irbis_server_ft.ini введены новые параметры.

В секции [FULLTEXT]:

PAGE0_BOOST=
определяет вес слова в тексте библиографии при полнотекстовом поиске (т.е. по запросу в окне "Я ИЩУ").
Значение по умолчанию 0, т.е. вес слова в библиографии такой же, как на страницах полного текста.
Если требуется дать словам библиографии больший вес, рекомендуемое значение - 10.

MAX_RELEVATION_MEM=
определяет максимальный результат полнотекстового поиска, который сортируется по релевантности.
Значение по умолчанию - 100000

В секции [MAIN]:

BIBLSEARCHPRIORITY=
Определяет включение или отключение специального режима полнотекстового поиска (т.е. поиска по запросу в окне "Я ИЩУ" ), который заключается в следующем:
Сначала выполняется поиск ТОЛЬКО ПО БИБЛИОГРАФИИ - и если находятся док-ты, в библиографии которых находятся ВСЕ слова, заданные в строке "Я ИЩУ", то полнотекстовый поиск (т.е. поиск по страницам полных текстов) НЕ ВЫПОЛНЯЕТСЯ и выдаются найденные док-ты. В противном случае, т.е. если таковые док-ты не находятся, выполняется стандартный полнотекстовый поиск.
Допустимые значения: 0 или 1.
где:
0 - специальный режим поиска отключён (по умолчанию)
1 - специальный режим поиска включён

Александр Иосифович, можно попросить об интерфейсной мелочи в серверном АРМ Администратор: чтобы в форме выбора БД из списка нажатие Enter приводило к выполнению команды "Выбор" и открытию выделенной БД. Как в клиентском варианте Администратора.

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

Куделя написал(а):
-------------------------------------------------------
> Во втором апдейте к версии 2022 в ФЛК записи для
> RDR добавили непреодолимый контроль для защиты 907
> поля от ручной корректировки
>
> if v907<>ref(mfn,v907) then '1Нельзя
> корректировать 907 поле!' else…
>
> В результате невозможно восстановить логически
> удаленную запись. Точнее восстановить-то, конечно,
> можно, а вот сохранить – нет. Потому что ref к
> логически удаленной записи не возвращает ничего.
> К сожалению, обойти эту ситуацию никак нельзя.
> &uf('N1,v907') здесь тоже не помогает, поскольку
> обращается все-таки к самой ранней предыдущей
> копии. В то же время проверять статус записи тоже
> смысла нет – максимум что можно сделать если
> &uf('+6')='0' это просто отменить проверку вовсе,
> ведь даже если в 907 поле вносились изменения, мы
> этого никак не узнаем из-за «зазора» между
> фактическими данными в БД (к которым обратиться
> форматер не может) и «полкой» куда программа
> поместила эти данные при восстановлении.
> Может быть имеет смысл доработать &uf('4')
> расширив перечень вариантов первого аргумента за
> счет «0»?
> То есть &uf('40,format') расформатировало бы
> именно активную запись, повторно обращаясь к базе.
> Ну то есть тот же ref(mfn,fmt), только
> игнорирующий статус записи в БД.

Более того, невозможно скопировать запись в другую бд, а так же сделать импорт из файла. Подскажите решение проблемы. Стоит задача занести первокурсников в БД Читателей, нужно их проверить на дублетность.

ИРБИС 64+ 2022.1 D2

Куделя написал(а):
-------------------------------------------------------
> Александр Иосифович, можно попросить об
> интерфейсной мелочи в серверном АРМ Администратор:
> чтобы в форме выбора БД из списка нажатие Enter
> приводило к выполнению команды "Выбор" и открытию
> выделенной БД. Как в клиентском варианте
> Администратора.
Нет такого в клиентском Администраторе. Работает двойной клик.

Александр Иосифович, не сочтите за назойливость, но очень прошу Вас рассмотреть возможность добавления поддержки выполнения пакетных заданий (команда с кодом 4) в произвольные пользовательские оперативные режимы в АРМ Книговыдача. После добавления Вами команды с кодом 3 это как та вишенка на торте, которой пока не достает для полного счастья!

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

Например при регистриции читателя в библиотеке нужно сгенерировать пароль доступа к личному кабинету в web-ИРБИС (или J-ИРБИС) и отправить читателю письмо с соответствующей информацией, или при выдаче читателю кода доступа к Литрес сообщить необходимую информацию читателю.

Или при завершении выдачи экземпляров книг отправить уведомление с содержанием электронного формуляра читателя (список экземпляров изданий, числящихся за читателем по состоянию на момент).

Или при простановке по какой-либо причине блокировки обслуживания читателя уведомить его об этом и о необходимых действиях.

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

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

Alio написал(а):
-------------------------------------------------------
> АРМ Книговыдача
>
> Предлагается новый режим ГОСТЕВЫЕ ПОСЕЩЕНИЯ -
> предназначенный для фиксирования групповых
> безымянных (гостевых) посещений.
> См. прикрепленные скриншоты.
>
> При фиксировании гостевых посещений выполняется их
> одновременная архивация (в БД RDR_ARH)
>
> Доступность данного режима определяется параметром
> в секции
>
> GUESTVISIT=
>
> который принимает два значения:
> 1 - режим доступен (по умолчанию)
> 0 - недоступен
>
> Следует напомнить, что архивные данные о
> книговыдачах и посещениях не отражаются в
> соответствующих словарях БД RDR - они учитываются
> только при получении соответствующих стат.форм.

Так как библиотеки обычно собирают статистику по категориям читателей, то было бы очень удобно иметь возможность указать в дополнении к коду посещения еще и код категории посетителей из справочника 50.mnu



Редактировано 1 раз. Последний раз 13.09.2023 17:06 пользователем А. Роман.

А что Вам мешает делать это в АРМе Каталогизатор?

А. Роман написал(а):
-------------------------------------------------------
> Alio написал(а):
> --------------------------------------------------
> -----
> > АРМ Книговыдача
> >
> > Предлагается новый режим ГОСТЕВЫЕ ПОСЕЩЕНИЯ -
> > предназначенный для фиксирования групповых
> > безымянных (гостевых) посещений.
> > См. прикрепленные скриншоты.
> >
> > При фиксировании гостевых посещений выполняется
> их
> > одновременная архивация (в БД RDR_ARH)
> >
> > Доступность данного режима определяется
> параметром
> > в секции
> >
> > GUESTVISIT=
> >
> > который принимает два значения:
> > 1 - режим доступен (по умолчанию)
> > 0 - недоступен
> >
> > Следует напомнить, что архивные данные о
> > книговыдачах и посещениях не отражаются в
> > соответствующих словарях БД RDR - они
> учитываются
> > только при получении соответствующих стат.форм.
>
> Так как библиотеки обычно собирают статистику по
> категориям читателей, то было бы очень удобно
> иметь возможность указать в дополнении к коду
> посещения еще и код категории посетителей из
> справочника 50.mnu
Что за странная идея? Гость - это одна из категорий читателей.

Alio написал(а):
-------------------------------------------------------
> А. Роман написал(а):
> --------------------------------------------------
> -----
> > Alio написал(а):
> >
> --------------------------------------------------
>
> > -----
> > > АРМ Книговыдача
> > >
> > > Предлагается новый режим ГОСТЕВЫЕ ПОСЕЩЕНИЯ -
> > > предназначенный для фиксирования групповых
> > > безымянных (гостевых) посещений.
> > > См. прикрепленные скриншоты.
> > >
> > > При фиксировании гостевых посещений
> выполняется
> > их
> > > одновременная архивация (в БД RDR_ARH)
> > >
> > > Доступность данного режима определяется
> > параметром
> > > в секции
> > >
> > > GUESTVISIT=
> > >
> > > который принимает два значения:
> > > 1 - режим доступен (по умолчанию)
> > > 0 - недоступен
> > >
> > > Следует напомнить, что архивные данные о
> > > книговыдачах и посещениях не отражаются в
> > > соответствующих словарях БД RDR - они
> > учитываются
> > > только при получении соответствующих
> стат.форм.
> >
> > Так как библиотеки обычно собирают статистику
> по
> > категориям читателей, то было бы очень удобно
> > иметь возможность указать в дополнении к коду
> > посещения еще и код категории посетителей из
> > справочника 50.mnu
> Что за странная идея? Гость - это одна из
> категорий читателей.

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



Редактировано 1 раз. Последний раз 13.09.2023 18:15 пользователем А. Роман.

Alio написал(а):
-------------------------------------------------------
> А что Вам мешает делать это в АРМе Каталогизатор?

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

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



Редактировано 1 раз. Последний раз 13.09.2023 18:28 пользователем А. Роман.

А. Роман написал(а):
-------------------------------------------------------
> Alio написал(а):
> --------------------------------------------------
> -----
> > А что Вам мешает делать это в АРМе
> Каталогизатор?
>
> В АРМ Каталогизатор далеко не всех сотрудников
> отделов обслуживания можно пускать.
> К тому же в отношении настроек ограничения
> действий тогда нужно будет ряд дополнительных
> настроек профилей выполнить (в отношении запретов
> на использование кнопок удаления записей,
> глобальной корректировки, экспорта и т.д. и т.п.)
> и вдобавок еще по одному клиентскому подключению
> на каждое рабочее место каждого отдела
> обслуживания для работы с АРМ Каталогизатор нужно
> будет предусмотреть.
>
> Но главное это дополнительное время, которое в
> случае использования АРМ Каталогизатор нужно будет
> тратить сотруднику отдела обслуживания на то,
> чтобы АРМ открыть, потом выполнить действие, потом
> АРМ Каталогизатор закрыть и переключиться на АРМ
> Книговыдача. Ведь задача и цель автоматизации в
> том и заключается, чтобы сокращать временные
> затраты на те цепочки действий, которые можно
> исключить за счет настройки пакетного выполнения
> этих действий.

Не убедительно.

А. Роман написал(а):
-------------------------------------------------------
> Alio написал(а):
> --------------------------------------------------
> -----
> > А. Роман написал(а):
> >
> --------------------------------------------------
>
> > -----
> > > Alio написал(а):
> > >
> >
> --------------------------------------------------
>
> >
> > > -----
> > > > АРМ Книговыдача
> > > >
> > > > Предлагается новый режим ГОСТЕВЫЕ ПОСЕЩЕНИЯ
> -
> > > > предназначенный для фиксирования групповых
> > > > безымянных (гостевых) посещений.
> > > > См. прикрепленные скриншоты.
> > > >
> > > > При фиксировании гостевых посещений
> > выполняется
> > > их
> > > > одновременная архивация (в БД RDR_ARH)
> > > >
> > > > Доступность данного режима определяется
> > > параметром
> > > > в секции
> > > >
> > > > GUESTVISIT=
> > > >
> > > > который принимает два значения:
> > > > 1 - режим доступен (по умолчанию)
> > > > 0 - недоступен
> > > >
> > > > Следует напомнить, что архивные данные о
> > > > книговыдачах и посещениях не отражаются в
> > > > соответствующих словарях БД RDR - они
> > > учитываются
> > > > только при получении соответствующих
> > стат.форм.
> > >
> > > Так как библиотеки обычно собирают статистику
> > по
> > > категориям читателей, то было бы очень удобно
> > > иметь возможность указать в дополнении к коду
> > > посещения еще и код категории посетителей из
> > > справочника 50.mnu
> > Что за странная идея? Гость - это одна из
> > категорий читателей.
>
> Это не моя идея, это то, с чем работает
> большинство общедоступных библиотек. Библиотекам
> нужно считать не общее число посетителей, а с
> распределением по категориям. Гости, они ведь
> разные бывают.

Загляните в БД RDR_ARH, после чего надеюсь поймете, что эта идея, мягко говоря, странная...

Куделя написал(а):
-------------------------------------------------------
> Во втором апдейте к версии 2022 в ФЛК записи для
> RDR добавили непреодолимый контроль для защиты 907
> поля от ручной корректировки
>
> if v907<>ref(mfn,v907) then '1Нельзя
> корректировать 907 поле!' else…
>
> В результате невозможно восстановить логически
> удаленную запись. Точнее восстановить-то, конечно,
> можно, а вот сохранить – нет. Потому что ref к
> логически удаленной записи не возвращает ничего.
> К сожалению, обойти эту ситуацию никак нельзя.
> &uf('N1,v907') здесь тоже не помогает, поскольку
> обращается все-таки к самой ранней предыдущей
> копии. В то же время проверять статус записи тоже
> смысла нет – максимум что можно сделать если
> &uf('+6')='0' это просто отменить проверку вовсе,
> ведь даже если в 907 поле вносились изменения, мы
> этого никак не узнаем из-за «зазора» между
> фактическими данными в БД (к которым обратиться
> форматер не может) и «полкой» куда программа
> поместила эти данные при восстановлении.
> Может быть имеет смысл доработать &uf('4')
> расширив перечень вариантов первого аргумента за
> счет «0»?
> То есть &uf('40,format') расформатировало бы
> именно активную запись, повторно обращаясь к базе.
> Ну то есть тот же ref(mfn,fmt), только
> игнорирующий статус записи в БД.

---

Есть несколько способов решить конкретно эту проблему:

1. Включить Xpft -- там ref(mfn, fmt) умеет читать удаленные и блокированные записи.
2. Использовать unfor('D..') он умеет читать удаленные и блокированные записи в любой реализации форматера.
3. Тупо сделать проверку преодолимой, заменив 1 на 2 в литерале

кроме этого надо учесть, что запись может быть новая. То есть сделать проверку mfn > 0.

Таким образом, наиболее универсальный вариант первой строки ФЛК для RDR такой:

if mfn > 0 and v907 <> &uf('D,@'mfn',v907') then '1Нельзя корректировать 907 поле!' else

НО и это не панацея, так как внешние приложения, например ИРБИС128, могут сами писать в 907 поле дату своего вмешательства и они это делают ДО скрипта автоввода, который в И64 занимается простановкой даты редактирования.
Лучше от этой строки просто отказаться, а редактирование 907 полей запрещать на уровне рабочих листов

AntonM написал(а):
-------------------------------------------------------

> Есть несколько способов решить конкретно эту
> проблему:
>
> 1. Включить Xpft -- там ref(mfn, fmt) умеет читать
> удаленные и блокированные записи.

Не у всех же Турбо

> 2. Использовать unfor('D..') он умеет читать
> удаленные и блокированные записи в любой
> реализации форматера.

Действительно, забыл про &uf(D)

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

АРМ Каталогизатор

Расширены возможности, связанные с технологией НАСТРОЙКА ПАРАМЕТРОВ (режим СЕРВИС-НАСТРОЙКА ПАРАМЕТРОВ), которая реализуется на основе РЛ подполей SETPRIV.WSS (имя по умолчанию).

Список параметров в SETPRIV.WSS (который находится в папке IRBIS64) ориентирован на БД ЭК и не имеет смысла для БД иного содержания, поэтому в предыдущей версии АРМа режим НАСТРОЙКА ПАРАМЕТРОВ блокировался при переходе на БД, отличные от ЭК.

В новой версии предполагается, что параметры настройки могут быть у любой БД - для этого в папке соответствующей БД должен быть РЛ подполей с именем SETPRIV.WSS (по умолчанию), т.е. если в папке БД отсутствует SETPRIV.WSS, то:
- если это БД ЭК, то для нее будет использоваться общий SETPRIV.WSS, который находится в папке IRBIS64;
- если это БД, отличная от ЭК, то режим НАСТРОЙКА ПАРАМЕТРОВ для этой БД будет заблокирован.

В качестве примера новой возможности предлагается setpriv.wss для БД RDR, который содержит единственный параметр настройки ЭТАП РАБОТЫ (в соответствии со справочником etr.mnu в папке RDR). В связи с этим откорректирован autoin.gbl для RDR, чтобы в записях читателей фиксировался этап работы (в 907 поле).

(Необходимо уточнить, что под параметрами здесь понимаются ФИКСИРОВАННЫЕ параметры настройки, т.е. ПРОИЗВОЛЬНЫЕ параметры являются общими для ВСЕХ БД)

Куделя написал(а):
>
> Реализовать возможность сортировки в "виртуальных
> справочниках" формируемых методом ввода 15
>
> ============
Сделал. По умолчанию задается сортировка по 2 колонке.
Но протестировать не могу. Попробуйте...
Ссылку послал в личку.

Alio написал(а):
-------------------------------------------------------
> Куделя написал(а):
> >
> > Реализовать возможность сортировки в
> "виртуальных
> > справочниках" формируемых методом ввода 15
> >
> > ============
> Сделал. По умолчанию задается сортировка по 2
> колонке.
> Но протестировать не могу. Попробуйте...
> Ссылку послал в личку.


Спасибо, Александр Иосифович! Все работает.
А можно по первой колонке сортировку сделать?

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

Куделя написал(а):
-------------------------------------------------------
> Alio написал(а):
> --------------------------------------------------
> -----
> > Куделя написал(а):
> > >
> > > Реализовать возможность сортировки в
> > "виртуальных
> > > справочниках" формируемых методом ввода 15
> > >
> > > ============
> > Сделал. По умолчанию задается сортировка по 2
> > колонке.
> > Но протестировать не могу. Попробуйте...
> > Ссылку послал в личку.
>
>
> Спасибо, Александр Иосифович! Все работает.
> А можно по первой колонке сортировку сделать?
Сделал

Alio написал(а):
-------------------------------------------------------

> > Спасибо, Александр Иосифович! Все работает.
> > А можно по первой колонке сортировку сделать?
> Сделал

Спасибо!

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

Очень не хватает возможности поиска фрагмента текста внутри записи в АРМ Каталогизатор.
По аналогии с режимом поиска поля по значению метки по Alt + Q.
Это было бы удобно как в РЛ записи, так и в окне буферной записи.

Также из удобств не хватает перемещения по предыдущим копиям записи нажатием на стрелки вверх/вниз, PgUp/PgDn



Редактировано 1 раз. Последний раз 24.10.2023 10:18 пользователем А. Роман.