Трудно описать ту радость которую я испытал получив долгожданный АРМ Книгообеспеченность! За последние несколько лет он поистине преобразился! Было огромным удовольствием наблюдать, как он вводит в запись 300 связок буквально за несколько секунд и осознавать сколь много проблем теперь ушло в прошлое.

Тем не менее, одна проблема – проблема переполнения записи, по-прежнему продолжает преследовать меня как владельца ИРБИС 32. Я давно убедился в том, что добавление любого дополнительного подполя к минимальному набору подполей 691 неизменно приводит к переполнению записи, и, естественно, сократил связку до минимума. Уже давно я был вынужден отказаться от ввода поле данных об уровне компонента, виде обучения, направлении и даже форме обучения(оставил только одну форму – ОЗО). Однако решить задачу внедрения интегрированной технологии книгообеспеченности без добавления подполей ^0, 9^, !^ всё-таки невозможно.
В то же время, очевидно, что эти подполя не несут никакой информационной нагрузки и могут быть легко сгенерированы на основе других имеющихся в связке данных. Отсюда напрашивается банальный вывод о том, что их нужно генерировать динамически, в самих форматах. Конечно, было бы неразумно говорить о необходимости переработки для этой цели двух десятков разнообразных скриптов. Но, к счастью есть и более простой выход: заменить все подполя на глобальные переменные имеющие идентичную структуру(вместо v691^0 – g691^0).

1. При помощи программы автозамены строк я заменил во всех форматах базы v691^0 на g691^0, v691^9 на g691^9, v691^! на g691^!.
2. Вынес формат генерации этих полей в отдельный файл и предусмотрел запись его результата в переменную 691(скрипт ниже)
3. Заменил в форматах &uf(‘Pg691^9’) на g691^8, &uf(‘Pg691^0’) на g691^1, &uf(‘Pg691^!’) на g691^5
(Необходимость замены &uf(‘P. . ’) обусловлена тем, что функция не поддерживает работу с глобальными переменными. Пришлось заранее исключить неоригинальные значения и записать данные лишь в некоторые повторения переменной g691. )
4. Добавил в основные форматы просмотра и выявленные мной глобальные корректировки ссылку на файл с форматом генерации подполей &uf(‘6!!e691’)

Пока я не вижу никаких побочных следствий описанного решения, а преимущества? которые оно обеспечивает, достаточно велики. Например, оно избавляет от необходимости постоянно поддерживать аткуальность ^0 и ^9 во всех глобальных корректировках, изменяющих какие-либо элементы связки. Т. е. повышает скорость сохранения.

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

Согласна с вашей позицией. Более того, в версии 8.1 при сохранении записи каталога будет формироваться поле 693 (неповторяющееся), в котором будут прописываться на текущий момент данные о количестве студентов, экземпляров и ККО. Т.к. это поле будет формироваться программно, уже получается, что надобность в подполях 0 и 9 исчезает. Я уже думала об отказе от них. Но при этом надо переделать форматы показа и таблицы. Я думаю, со временем это будет сделано.