А. Роман написал(а):
-------------------------------------------------------
> Может быть полезен функционал по экспорту записи
> из окна просмотра буферной записи и из окна
> просмотра предыдущих копий записи.
Смысл?

Да вот, хотябы: [irbis.elnit.org]

Вы полагаете, что ЭТО достаточный аргумент?

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

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

Но предложу вариант на продумывание общей кнопки для снятия информации о состоянии ИРБИСа в конкретный момент.
Т.е. что-то типа дампа параметров системы, который содержит основные характеристики и состояния, в котором система находится.
Пользователь отправляет такой дамп и вопросов больше к пользователю не нужно. Поскольку все недопонимания и возникают на этом этапе.

GLUKa написал(а):
-------------------------------------------------------
> Alio написал(а):
> --------------------------------------------------
> -----
> > Sergienko написал(а):
> >
> --------------------------------------------------
>
> > -----
> > > Предлагаются интересные решения. Очень
> > понравилось
> > > идеи Галины Арноси для АРМ "Кинговыдача".
> Одно
> > из
> > > них, сделать возможность в кнопке посещения
> на
> > > гостевой читательской записи указывать
> > количество
> > > посещений.
> > И сколько же повторений 40 поля будет в этой
> > записи???
> Можно ведь использовать автоматическое
> архивирование записи :)
Принимается.

GLUKa написал(а):
-------------------------------------------------------
> В Арм Книговыдача в режиме выдача без заказа. Для
> выдачи одного издания или групповой выдачи было бы
> здорово иметь возможность переключать, Выдача с
> единовременным возвратом или обычная выдача.
Принимается.

GLUKa написал(а):
-------------------------------------------------------
> В Арм Книговыдача в режиме выдача без заказа. Для
> выдачи одного издания или групповой выдачи было бы
> здорово иметь возможность переключать, Выдача с
> единовременным возвратом или обычная выдача.
Принимается.
спасибо

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



Редактировано 1 раз. Последний раз 24.07.2023 07:16 пользователем GLUKa.

Alio написал(а):
-------------------------------------------------------
> GLUKa написал(а):
> --------------------------------------------------
> -----
> > Alio написал(а):
> >
> --------------------------------------------------
>
> > -----
> > > Sergienko написал(а):
> > >
> >
> --------------------------------------------------
>
> >
> > > -----
> > > > Предлагаются интересные решения. Очень
> > > понравилось
> > > > идеи Галины Арноси для АРМ "Кинговыдача".
> > Одно
> > > из
> > > > них, сделать возможность в кнопке посещения
> > на
> > > > гостевой читательской записи указывать
> > > количество
> > > > посещений.
> > > И сколько же повторений 40 поля будет в этой
> > > записи???
> > Можно ведь использовать автоматическое
> > архивирование записи :)
> Принимается.

спасибо

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

АРМ Книговыдача

Предлагается новый режим ГОСТЕВЫЕ ПОСЕЩЕНИЯ - предназначенный для фиксирования групповых безымянных (гостевых) посещений.
См. прикрепленные скриншоты.

При фиксировании гостевых посещений выполняется их одновременная архивация (в БД RDR_ARH)

Доступность данного режима определяется параметром в секции [MAIN]

GUESTVISIT=

который принимает два значения:
1 - режим доступен (по умолчанию)
0 - недоступен

Следует напомнить, что архивные данные о книговыдачах и посещениях не отражаются в соответствующих словарях БД RDR - они учитываются только при получении соответствующих стат.форм.



Редактировано 2 раз. Последний раз 24.07.2023 20:28 пользователем Alio.

Можно попросить посмотреть логику отбора в карман результатов ПОСЛЕДОВАТЕЛЬНОГО поиска в АРМ Каталогизатор?
Дело в том, что когда выполняешь отбор в "Карман", поиск (судя по длительности процесса) выполняется повторно, а не пользуется только что полученным списком mfn.

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

Куделя написал(а):
-------------------------------------------------------
> Можно попросить посмотреть логику отбора в карман
> результатов ПОСЛЕДОВАТЕЛЬНОГО поиска в АРМ
> Каталогизатор?
> Дело в том, что когда выполняешь отбор в "Карман",
> поиск (судя по длительности процесса) выполняется
> повторно, а не пользуется только что полученным
> списком mfn.
При переходе к следующей порции по результату последовательного поиска собственно последовательный поиск ВСЕГДА повторяется - и никак иначе.

GLUKa написал(а):
-------------------------------------------------------
> GLUKa написал(а):
> --------------------------------------------------
> -----
> > В Арм Книговыдача в режиме выдача без заказа.
> Для
> > выдачи одного издания или групповой выдачи было
> бы
> > здорово иметь возможность переключать, Выдача с
> > единовременным возвратом или обычная выдача.
> Принимается.
> спасибо

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

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

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

В принципе, благодаря расширению команд произвольных пользовательских режимов (за что еще раз отдельное СПАСИБО!) это можно сделать самостоятельно продвинутым пользователям, но в принципе, т.к. потребность не частная, а для многих пользователей ИРБИС общая, то правильнее было бы согласовать технологию с разработчиками.

Суть предложения такая: организовать две кнопки. Одна для подтверждения личности читателя, вторая для подтверждения согласия с результатом обслуживания (книговыдачи).

Первая кнопка: для подтверждения личности читателя.
По ней сотрудник библиотеки может ввести одноразовый пин-код, который ему сообщит читатель при посещении библиотеки для того, чтобы не предъявлять паспорт или иной документ подтверждающий личность.
У подавляющего большинства библиотек читательские билеты не содержат ни фотографии ни даже ФИО и не нозволяют идентифицировать читателя. Поэтому во избежание ситуаций пользования чужими ЧБ необходимо простое подтверждение того, что этот читатель имеет доступ к ЛК (т.е. ему были выданы № ЧБ и пароль для доступа, которые он должен держать в секрете от других).

Сам пин-код может создаваться читателем в ЛК одного из веб-модулей или формироваться сотрудником библиотеки и направляться читателю по электронной почте (еще раз отдельное спасибо за реализацию оперативного режима с командой 3 в АРМ Книговыдача). Храниться пин-коды должны в зашифрованном виде в отдельной БД, например RDR_SIGN. Технология - по аналогии с БД RQST - создание записи с идентификатором и GUID записи читателя, хешем пин-кода и 907 полем с датой и временем, а также этапами - создание, применение и м.б. удаление и логином ответственного за действие (читателя, если он создал пин-код или сотрудника, который его применил).

При формировании записей с пин-кодами сотрудником библиотеки можно отправлять уведомление читателю по электронной почте или выводить пин-код в ЛК читателя, но при этом шифровать пин-код после отправки письма по электронной почте. Если пин-код зашифрован, то в ЛК его отображать не нужно (в ЛК читатель и сам может сгенерировать пин-код).


Вторая кнопка: подтверждение согласия с результатом обслуживания читателя (чуть более сложная технология).
Генерация пин-кода м.б. идентичной предыдущей опции. Для простановки согласия с результатами обслуживания читатель также может сообщить пин-код сотруднику (как альтернатива - нажать на кнопку "Согласиться" под списком выданной литературы в ЛК одного из Web-модулей.

При этом к записи пин-кода в БД RDR_SIGN нужно добавить данные из поля 40 по состоянию на момент простановки согласия.

Архивирование информации по подписям можно вести в БД SIGN_ARH.



Редактировано 2 раз. Последний раз 25.07.2023 11:47 пользователем А. Роман.

Alio написал(а):
-------------------------------------------------------
> Куделя написал(а):
> --------------------------------------------------
> -----
> > Alio написал(а):
> >
> --------------------------------------------------
>
> > -----
> >
> > > М.б. это стоит реализовать на основе того,
> что
> > > клиентский Администратор будет запускаться
> БЕЗ
> > > ИСПОЛЬЗОВАНИЯ ЛИЦЕНЗИИ?
> >
> > Это самое правильное решение. Все-таки
> > Администратор это больше сервисный модуль.
> Наверно, сделаем так: клиентский Администратор
> сможет подключаться без использования серверной
> лицензии ТОЛЬКО в том случае, когда все лицензии
> исчерпаны.
Однако... Запутал сам себя. Клиентский Администратор и СЕЙЧАС (в действующих версиях начиная с 2020) запускается без расходования серверной лицензии.



Редактировано 1 раз. Последний раз 25.07.2023 13:48 пользователем Alio.

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



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

Еще два пожелания по доработке режима работы с карманом:
1. обеспечить работу не столько с MFN, сколько с GUID записей.
Т.е. при сохранении Кармана преобразовывать MFN в GUID и наоборот, при открытии файла кармана преобразовывать GUID в MFN.
2. добавить кнопку удаления отмеченных MFN/GUID записей из кармана.

АРМ Книговыдача

Предлагается новый режим РЕЙТИНГ ИЗДАНИЙ. (см. прикрепленные скриншоты)

Режим предназначен для оперативного представления изданий, наиболее востребованных читателями за определенный год.

Данные представляются в виде двух таблиц:
- наиболее востребованные электронные издания (имеются в виду читательские обращения к полным текстам - 955 поле - через Web-ИРБИС64)
- наиболее востребованные бумажные издания (имеются в виду книговыдачи, зафиксированные в БД RDR и RDR_ARH)

Обе таблицы (как и все остальные в АРМе) - "живые", т.е. в них можно менять порядок и размеры колонок, а также колонку для сортировки.

В таблицах предусмотрены колонки для отображения произвольных данных из документов.
Содержимое этих колонок формируется с помощью соответствующих форматов:
ebookmax_dop - для электронных изданий
pbookmax_dop - для бумажных изданий
Предполагается, что пользователи будут настраивать эти форматы по собственному усмотрению. В дистрибутивном варианте:
- по формату ebookmax_dop выводится шифр издания
- по формату pbookmax_dop выводится год издания.

Алгоритм формирования рейтинга изданий реализован исключительно на форматах, а именно:
ebookmax, ebookmax0, ebookmax_dop - для рейтинга электронных изданий
pbookmax, pbookmax0, pbookmax1, pbookmax_dop - для рейтинга бумажных изданий.
Все форматы находятся в папке DEPOSIT.
В форматах используются явные константы:
5000 - максимальное кол-во отбираемых документов (за год)
100 - максимальное кол-во строк в таблицах.

Для более детального анализа рейтинга изданий (а именно - можно задавать произвольный временной период анализа) предлагаются выходные табличные формы:
ebookmax_tab - для электронных изданий (по БД LICH)
pbookmax_tab - для бумажных изданий (по БД RDR с учетом данных в архиве RDR_ARH)

Важное замечание
При большом объеме БД читателей и большом кол-ве сведений о книговыдаче в записях читателей данный режим может выполняться чрезвычайно долго. В этом случае необходимо пользоваться технологией архивирования сведений о книговыдаче (см. раздел АРМ Книговыдача в релизе системы 2016.1). При этом следует применять параметр профиля пользователя
AUTOARHIV=1



Редактировано 4 раз. Последний раз 14.08.2023 11:32 пользователем Alio.

АРМ Книговыдача

Предлагается новый режим РЕЙТИНГ ЧИТАТЕЛЕЙ. (см. прикрепленные скриншоты)

Режим предназначен для оперативного представления наиболее активных читателей за определенный год (разумеется, с точки зрения книговыдач - электронных и бумажных изданий).

Данные представляются в виде двух таблиц:
- наиболее активные читатели электронных изданий (имеются в виду читательские обращения к полным текстам - 955 поле - через Web-ИРБИС64)
- наиболее активные читатели бумажных изданий (имеются в виду книговыдачи, зафиксированные в БД RDR и RDR_ARH)

Обе таблицы (как и все остальные в АРМе) - "живые", т.е. в них можно менять порядок и размеры колонок, а также колонку для сортировки.

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

Алгоритм формирования рейтинга читателей реализован исключительно на форматах, а именно:
ereadermax, ereadermax0, ereadermax_dop - для рейтинга читателей электронных изданий
preadermax, preadermax0, preadermax1, preadermax_dop - для рейтинга читателей бумажных изданий.
Все форматы находятся в папке DEPOSIT.
В форматах используются явные константы:
5000 - максимальное кол-во отбираемых документов (за год)
100 - максимальное кол-во строк в таблицах.

Для более детального анализа рейтинга читателей (а именно - можно задавать произвольный временной период анализа) предлагаются выходные табличные формы:
ereadermax_tab - для читателей электронных изданий (по БД LICH)
preadermax_tab - для читателей бумажных изданий (по БД RDR с учетом данных в архиве RDR_ARH)

(См. ВАЖНОЕ ЗАМЕЧАНИЕ в предыдущем сообщении)



Редактировано 2 раз. Последний раз 14.08.2023 11:34 пользователем Alio.

Alio написал(а):
-------------------------------------------------------
> GLUKa написал(а):
> --------------------------------------------------
> -----
> > GLUKa написал(а):
> >
> --------------------------------------------------
>
> > -----
> > > В Арм Книговыдача в режиме выдача без заказа.
> > Для
> > > выдачи одного издания или групповой выдачи
> было
> > бы
> > > здорово иметь возможность переключать, Выдача
> с
> > > единовременным возвратом или обычная выдача.
> > Принимается.
> > спасибо
>
> Для групповой выдачи без заказа сделать это сложно
> и, считаю, неоправданно.
> А для индивидуальной выдачи без заказа -
> возможно...

Реализация этой идеи оказалась крайне неуклюжей, поэтому решил от нее отказаться...

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

А. Роман написал(а):
-------------------------------------------------------
> Еще два пожелания по доработке режима работы с
> карманом:
> 1. обеспечить работу не столько с MFN, сколько с
> GUID записей.
> Т.е. при сохранении Кармана преобразовывать MFN в
> GUID и наоборот, при открытии файла кармана
> преобразовывать GUID в MFN.
Нет.

> 2. добавить кнопку удаления отмеченных MFN/GUID
> записей из кармана.
Так ли это необходимо?

Alio написал(а):
-------------------------------------------------------
> А. Роман написал(а):
> --------------------------------------------------
> -----
> > Еще два пожелания по доработке режима работы с
> > карманом:
> > 1. обеспечить работу не столько с MFN, сколько
> с
> > GUID записей.
> > Т.е. при сохранении Кармана преобразовывать MFN
> в
> > GUID и наоборот, при открытии файла кармана
> > преобразовывать GUID в MFN.
> Нет.

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

>
> > 2. добавить кнопку удаления отмеченных MFN/GUID
> > записей из кармана.
> Так ли это необходимо?

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

Разве не логично, что если можно добавлять записи в список, то должна быть и возможность удалять записи из списка?

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

Спасибо!

P.S. Сегодня столкнулись с ситуацией, что в директории с АРМами отсутствовал файл приложения для генерации QR-кодов. При этом не выводилось никаких сообщений об ошибке.

Возможно ли добавить вывод сообщения, в случае если при работе АРМ должен использоваться какой-либо файл (приложение, ini, mnu, wss или pft) и этот файл отсутствует в системе?

Например, окно с предупреждением, в котором будет блок со скроллбаром и списком отсутствующих файлов.



Редактировано 1 раз. Последний раз 17.08.2023 19:23 пользователем А. Роман.

Предложение - для АРМ Администратор клиентский добавить возможности:

1. Создавать новую БД по образцу существующей.
2. Импортировать записи (с указанием ТВП, ФЛК, автоввода, актуализации, импорта со слиянием, фильтрами).
3. Реорганизовать файл БД с исключением удаленных записей.

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

А. Роман написал(а):
-------------------------------------------------------
> Предложение - для АРМ Администратор клиентский
> добавить возможности:
>
> 1. Создавать новую БД по образцу существующей.
> 2. Импортировать записи (с указанием ТВП, ФЛК,
> автоввода, актуализации, импорта со слиянием,
> фильтрами).
> 3. Реорганизовать файл БД с исключением удаленных
> записей.
По поводу последнего - исключено.

Уважаемый Александр Иосифович, полнотекстовым функционалом пользуется не так много библиотек (по нашим отценкам не более 30-40%). Из них более половины ведут БД ЭБ отдельно от БД ЭК.
Ведение записей полнотекстовых ресурсов в тех же БД, где ведутся записи печатных изданий далеко не всегда может быть оправдано. И в J-ИРБИС и в ИРБИС128 есть технологии формирования виртуальных БД в которые включаются несколько физических БД. Тут есть свои плюсы и свои минусы.
Может стоит не рубить с плеча, а все же поискать компромиссные варианты решения проблемы?

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

А. Роман написал(а):
-------------------------------------------------------
> Уважаемый Александр Иосифович, полнотекстовым
> функционалом пользуется не так много библиотек
> (по нашим отценкам не более 30-40%). Из них более
> половины ведут БД ЭБ отдельно от БД ЭК.
> Ведение записей полнотекстовых ресурсов в тех же
> БД, где ведутся записи печатных изданий далеко не
> всегда может быть оправдано. И в J-ИРБИС и в
> ИРБИС128 есть технологии формирования виртуальных
> БД в которые включаются несколько физических БД.
> Тут есть свои плюсы и свои минусы.
> Может стоит не рубить с плеча, а все же поискать
> компромиссные варианты решения проблемы?
>
> Нелепо - вводить новые записи в пустые места (в
> т.н. дыры в БД), чем занимаются библиотекари,
> удаляющие записи и не пыполняющие реорганизацию БД
> с исключением удаленных физически записей.
> Нелогично располагать новые записи в начале или
> середине БД в ситуации, когда принято и совершенно
> логично, что новые записи идут в конце БД.
> Да, проблема отбора решается выполнением поисковых
> запросов по дате ввода, но этим к большому
> сожалению по моим наблюдениям не пользуется более
> 80% библиотекарей, считающих количество документов
> в БД по максимальному MFN.
> Кстати, в этой связи и в АРМ Каталогизатор в
> панели информации о БД прошу Вас вывести цифру:
> кол-во удаленных записей, чтобы в таких случаях
> сотрудники не обманывались, считая, кол-во записей
> в БД.
Если удастся реализовать идею автоматического сохранения новых документов в "дырках", этот режим будет исключен.

А. Роман написал(а):
-------------------------------------------------------
> Предложение - для АРМ Администратор клиентский
> добавить возможности:
>
> 1. Создавать новую БД по образцу существующей.
Хотелось бы услышать еще одного пользователя, которому нужен этот режим в клиентском Администраторе. А заодно - узнать о РЕАЛЬНОЙ ситуации, когда нужен этот режим...


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

> 3. Реорганизовать файл БД с исключением удаленных
> записей.
Нет.