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

При попытке полностью просмотреть термин словаря выдаётся пустое окно. При попытке вставить данные, связанные с термином(щелчок мышью) выдаётся - List index out of bounds(0).
Термин - Заглавие, на нём 9 записей с книгообеспеченностью, самая большая из которых имеет объём 20 килобайт в текстовом формате.


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


PS
Нетрудно догадаться, сколько времени мне пришлось потратить на выявление причины такой ошибки. Я очень надеюсь, что разработчики не пожалеют своего времени на то, чтобы её устранить.

А можно подробностей? Как ваша тема оказалась в Комплектаторе и как словарь заглавий соотносится с 691-м полем? Не совсем понятно об чём речь.

P.S. Побольше бы конструктива, да и к людям помягше надо бы, а то ведь скоро вашим именем можно будет разработчиков пугать. :)

Действительно, подобные ситуации следует описывать подробно, если хотите, чтобы разработчики разобрались. Книгообеспеченность здесь не при чем. Может у вас развалился словарь, а может и база. Для записи допустим размер <=32К.

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

> А можно подробностей?

Да, конечно. Когда-то у меня даже было намерение написать по поводу книгообеспеченности целую поэму…
Как я понимаю, вы работаете по ручной технологии, т.е. база VUZ у вас не используется и, следовательно, с проблемой переполнения вы не знакомы. У нас же база VUZ была конвертирована из базы учебного отдела и содержит самые полные данные, необходимые работы для технологии «Уникальная дисциплина».
В поле 691 добавляются связки данных:

^W190/25^DИностранный язык^BИЯ^AФИТСУ^F1^I190^C21010^N651900^Oо^HПУИС

(По мысли разработчиков, подполе ^W должно было бы содержать Иностр. яз./25 – т.е. ещё больше, а новый модуль книгообеспеченности к тому же, в полтора раза удлиняет такие связки, добавляя и подполя ^!, ^0.)

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

На сегодняшний день, при наличии в ИРБИС встроенных функций для поддержки реляционных связей(&uf(‘7)) эта технология представляется, ну мягко говоря, неоправданной: поле ^W однозначно идентифицирует нужную связку данных(запись) в VUZ. Не говорю здесь про архитектуру базы VUZ, поскольку для её описания я просто не нахожу нужных слов.

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

> Как ваша тема оказалась в Комплектаторе
> и как словарь заглавий соотносится с 691-м полем?

Я написал об этом в первых строках своего сообщений. Позвольте мне процитировать самого себя:
«существующая технология книгообеспеченности приводит к переполнению записей и возникновению самых необычных ошибок. Здесь рассматривается случай, когда ошибка вызвана даже не приближением объёма записи к максимальному, а некорректной работой программы и искусственным "принижением" ей этого "максимума".»

> P.S. Побольше бы конструктива, да и к людям помягше надо бы,
> а то ведь скоро вашим именем можно будет разработчиков пугать.

80% моего рабочего времени уходит на исправление, выявление или обход ошибок разработчиков. Разве это не конструктивная деятельность? ;)

PS
Да, между прочим, разве ваша библиотека использует Комплектатор? Если да, то интересно, в каких процессах?

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

> Действительно, подобные ситуации следует описывать подробно,
> если хотите, чтобы разработчики разобрались.

Думаю, лучше всего было бы, если бы я прислал вам свои записи(15 штук) + формат просмотра словаря. Это сразу же избавило бы нас от необходимости обсуждать эту проблему на «теоретическом» уровне.

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

> Книгообеспеченность здесь не при чем. Может у вас развалился
> словарь, а может и база.
> Для записи допустим размер <=32К.

Вы хотите сказать, что существующая технология работы с книгообеспеченностью не приводит к переполнению записей, или, что в данном случае предполагаемый вами «развал» словаря или базы не может быть связан с книгообеспеченностью?



Отправка отредактированного (19-12-05 20:12)

Не совсем понял, что имеется ввиду под "ручной технологией"?

Пока работю с задачей КО таким образом:

1. Система КО, находится в отдельной папке (БД VUZ и БД IBIS. От использования БД RDR в этой задаче, видимо придется отказаться)

2. Все повторения 910 поля со статусом 0 и U заменяются на одно повторение с суммарным кол-вом экз., что существенно уменьшает размер записи.

3. Кол-во студентов, изучающих дисциплину вводится, как это и предусмотрено, в поле 68^z записи типа VUZ.


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

Это не есть факт! Как Вы предполагаете, студент может на втором и последующих семестрах изучать высшую математику по одному и тому же учебнику? То же и с физикой и с БОЛЬШИНСТВОМ других дисциплин.
Кроме того, достаточно часты ситуации, когда для одних и тех же дисциплин разных специальностей используются разные учебники. Отсюда опять же сокращение числа повторений 691-го поля.
Так что формула не столь однозначна, как Вы ее нарисовали.


>Теперь, я полагаю, нетрудно понять, почему переполнение записей просто неизбежно.

При грамотном подходе (не только на уровне библиотеки, а еще и на уровне работы методистов кафедр) можно добиться хороших результатов работы системы!

P.S. Письмо получил, спасибо, погрызу обязательно.

А. Роман писал(а):
> Не совсем понял, что имеется ввиду под "ручной
> технологией"?

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

> От использования БД RDR в этой задаче, видимо придется
> отказаться)

Большая просьба, пару слов по этому поводу. У меня уже лежит база студентов и я пообещал внедрить интегрированную технологию. Какие сложности возникли в связи с этим у вас?

> 2. Все повторения 910 поля со статусом 0 и U
> заменяются на одно повторение с суммарным кол-вом экз., что
> существенно уменьшает размер записи.

Насколько я знаю, вы внедрили штрихкодовую книговыдачу ещё до того, как модуль книговыдачи был доработан для выдачи многоэкземплярной литературы. Интересно, как вы поступали с многоэкземплярной литературой тогда и как сейчас?

> > Количество таких связок = количество
> специализаций(специальностей) * число семестров, в течении
> которых читается предмет * количество форм обучения *7
> количество названий дисциплины, по которой рекомендуется книга.
>
> Как Вы предполагаете, студент может
> на втором и последующих семестрах изучать высшую математику
> по одному и тому же учебнику?

С этим согласен, но есть ещё и дополнительная литература, которая может использоваться на протяжении всего периода обучения.

Было бы интересно узнать ваши цифры.
У нас это:
Физика - 247 связок
Высшая математика - 346
Иностранный язык - 403

> Так что формула не столь однозначна, как Вы ее нарисовали.

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

> При грамотном подходе (не только на уровне библиотеки, а еще
> и на уровне работы методистов кафедр) можно добиться хороших
> результатов работы системы!

Роман неужели вы, положа руку на сердце, можете сказать, что это хорошая технология? Отвечать не нужно. Я хорошо понимаю, что каждый квалифицированный дилер прекрасно знает, с ЧЕМ он имеет дело. ;)



Отправка отредактированного (20-12-05 13:29)

А применяете ли Вы возможность описания дисциплины в БД VUZ и, соответствеенно, в БД ЭК по сокращенной схеме - если не указана специальность, то можно опускать все остальные реквизиты, кроме семестра (например, для всех факультетов, всех форм обучения на определенных семестрах)? Число связок значительно уменьшится.
Но этот вариант работает только с БД читателей.

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

Поле 691 может выглядеть, например, так
^! 1^WХЛ/1^DХудож.литература^IХЛ^BХЛ^SГСЭ^KФК^F1^0-S1 (для всех студентов 1-го курса).
Версия 2004.1 - см. RELEASE_L2004_1.doc. Раздел Инф-техн. обеспечение - IBIS-п.22.4).
Главное при этом было в изменении формирования термина-связки (?...) в RDR.FST
Еще одно дополнение с целью сокращения числа связок было введено в 2004.2 (см. RELEASE_2004_2.doc. Раздел Инф-техн. обеспечение - RDR) для условия, когда шестизначный код специализации и шестизначный код специальности имеют одинаковые первые 4 цифры и различаются последними двумя цифрами (у специальности - 00, у специализации не 00) - обеспечивается формирование дополнительного термина - связки ‘?...’, содержащего код специальности, если в записи RDR в 90^c введен код специализации (студент откликается и на специализацию, и на специальность).

Да, действительно, это достаточно удобное решение, но только при соблюдении трёх условий:
1. Изначально должна применяться интегрированная технология. Для нас оно невыполнимо: уже год, как мы работаем только с базой VUZ. Из-за обновления базы, даже написание трёхэтажных глобальных корректировок здесь не поможет.
2. Не применяется модуль Книгообеспеченности, в котором эти "тонкости" не поддерживаются. Мы же, несмотря на кривизну модуля, собираемся его использовать.
3. Данные по книгообеспеченности используются у нас для обеспечения поиска по специальности. Если мы применим ваше решение, поиск по специальности будет невозможен.

Я ещё раз замечу, что мне совершенно непонятно, почему при выработке технологии не применялись возможности реаляционных связей. Ведь такие функции как &unifor('D позволяют без всякого труда получить любой элемент связки непосредственно из базы VUZ по идентификатору в ^W.

Если бы у меня было немного больше времени и я лучше знал бы инегрированную технологию(не приходилось раньше работать с VUZ ) , то нажал бы замечательное сочетание ALT+F7, нашел бы в основной базе все форматы с упоминанием поля 691 и заменил вы в них всё на что-нибудь такое: &uf('DVUZ,?NDUN=',v691^w,'?,v93').

Мне не ясно, зачем задавать такие элементы, как идентификатор дисциплины, когда он уже содержится в уникальном номере и его можно выделить &uf('g0/',v691^w). Я просто не понимаю назначения полей ^!, где дублируется семестр и ^0, куда помещается свёртка связки, хотя, должно быть, они играют какую-то роль в интегрированной технологии.

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

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

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

Я написал всё это вовсе не для того, чтобы развлечься пустой критикой. Как и другие пользователи, я действительно заинтересован в нормальном развитии системы.

PS
Я правильно вас понял, сокращённый вариант требует ещё и изменений в базе VUZ?



Отправка отредактированного (22-12-05 01:19)

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

<&uf('DVUZ,?NDUN=',v691^w,'?,v93')>
Да, такую функцию мы знаем (правда, появилась она много позже, чем была разработана основная технология)
Однако, если в записях БД ЭК будут введены только 691^W или 691^U, то можно себе представить, как возрастет время создания словаря, если все термины, связанные с КО, будут браться по ссылке, то же относится и к получению всех выходных форм.

А пользуетесь ли Вы переносом в поле 691 полных данных из БД VUZ через подполе Дисциплина в режиме мультиввода (в табличном виде), когда за одно обращение могут быть введены все экз-ры поля 691?

Сокращённый вариант не требует изменений в базе VUZ.
Сокращённый вариант работает и в АРМ Книгообеспеченность, но также при использовании БД RDR.

Дунаевская С.М. писал(а):

> Однако, если в записях БД ЭК будут введены только 691^W или
> 691^U, то можно себе представить, как возрастет время создания
> словаря, если все термины, связанные с КО, будут браться по
> ссылке, то же относится и к получению всех выходных форм.

Согласен. Только проблема скорости решается на аппаратном уровне, а «проблема 32 килобайт» - нет. Кроме того, в ходе тестирования замечательного модуля Книгообеспеченности, я должен был посадить сотрудника, работающего с книгообеспеченностью за локальную базу, отключить актуализацию и автоввод и обеспечить возможность синхронизации. В сетевом варианте время вставки одной дисциплины доходило до 46 минут(!!!), на это не хватало даже ночи, и, к тому же, книгообеспеченность лишала возможности работать других сотрудников.(надо буде об этом отдельно написать) Думаю, скорость - не главный аргумент в вопросе о книгообеспеченности. ;)
Что касается выходных форм, отбор занимает у нас в несколько раз больше времени, чем форматирование. Небольшая задержка здесь допустима.
Наконец, глобальные переменные и новые функции делают возможным форматирование записи на основе одной(в редких случаях двух) записи DISC, без непрерывного обращения к словарю и поиска DUNIC .


> <&uf('DVUZ,?NDUN=',v691^w,'?,v93')>
> Да, такую функцию мы знаем (правда, появилась она много
> позже, чем была разработана основная технология)

Понимаю, что когда вы разрабатывали технологию, то имели дело с первыми пентиумами. Но, именно поэтому сейчас необходим пересмотр многих решений.


> А пользуетесь ли Вы переносом в поле 691 полных данных из БД
> VUZ через подполе Дисциплина в режиме мультиввода (в табличном
> виде), когда за одно обращение могут быть введены все экз-ры
> поля 691?

Да, пользовались. После этого сотрудник закатывал мне истерики: «Я не могу 1924 раза кликать мышью, я схожу с ума, посмотрите, на кого я похожа! ! !».

> Сокращённый вариант работает и в АРМ Книгообеспеченность, но
> также при использовании БД RDR.

Не могли бы вы уточнить, как реализована эта возможность. По логике вещей, упрощённая конструкция могла бы вставляться при выделении ВСЕХ специальностей, связанных с дисциплиной, или при выделении дисциплины на ЛЕВОЙ панели. Этого, однако, не происходит.

<1924 раза> - как только первые Пользователи с этим столкнулись, был введен сокращенный вариант.

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

Дунаевская С.М. писал(а):

> <1924 раза> - как только первые Пользователи с этим
> столкнулись, был введен сокращенный вариант.

Светлана Михайловна, вы сами признавали, что сокращённый вариант не работает без базы читателей. Как же мы могли его использовать? Мне представляется, что единственным вполне последовательным способом автоматического добавления этих данных является заимствование из VUZ при помощи алгоритма в autoin.gbl.(если забыть о 32 килобайтах) Сам я не стал прорабатывать этот вариант, поскольку модуль книгообеспеченности делал доработки подобного рода бессмысленными.

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

очагова писал(а):

> у меня впечатление, что вы
> тестируете не новый АРМ Книгообеспеченности, а
> Книгообеспеченность в рамках АРМа Каталогизатор.

Я тестировал оба АРМа но пока ещё не успел сойти с ума настолько, чтобы не быть в состоянии отличить один от другого. ;)

> В новом АРМе не может сохранение идти 45 мин.,

В своём сообщении я писал, что автоввод и актуализация была отключена. Я пробовал вообще убрать все операторы из CHK691.gbl, но результат остался практически тем же. Время на вставку(отбор, фильтрация) записей возрастало в арифметической прогрессии. Я уже не говорю о качестве самого алгоритма вставки. Это отдельный вопрос.
Повторяю, если у вас действительно вызывает сомнение, что модуль работает таким образом, пожалуйста, я пришлю несколько записей и вы сможете сами во всём убедится.
Точные точное время замера на локальной машине(Cel 1700/256 под Win2k) связок иностранного иностранного (пример повторения приведён выше, связок - 368) - 26 минут. Надо ли говорить, сколько это занимало в сетевом режиме?

> т.к. там можно отказаться от установки связей и автоввод будет
> минимальный.

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

Кириллу Соколинскому.
Пришлите, пожалуйста, вашу БД VUZ (и если можно RDR, *.mst+*.xrf), я потестирую. Только шлите по адресу alio@gpntb.ru - для Очаговой. Судя по ссылки на файл chk691, у вас какой-то старый вариант. Сейчас в дистрибутиве такого нет.

Присылаю вам свою базу. Отправлять RDR пока бессмысленно: мы ещё не пользуемся ей. Комментарии по поводу некоторых изменений я написал в отдельной ветке.

«Судя по ссылки на файл chk691, у вас какой-то старый вариант. Сейчас в дистрибутиве такого нет.»

Да, но сейчас в дистрибутиве есть файл Move691.gbl, который полностью аналогичен CHK691.gbl.

В Кнмгообеспечении при выводе записи из БД ВООК на корректировку в поле 964 не высвечивается словарь Тематический рубрикатор. Что надо сделать?
Ирина Георгиевна

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

Как и анонсировал Кирил при некоторых случаях на Ирбис 32 база ЭК может и посыпаться. Это и произошло. Сейчас временно удалил из ЭК все данные о КО, кроме УНД, по которому в посследствии восстановлю всю информацию. Скажите, действительно ли нужно хранить в ЭК такое количество информации? Можно ли настроить перенос данных о контингете с условием:
1. если книга используется в нескольких семестрах, то передавать не несколько строк, а одну с перечнем семестров;
2. если книга используется для нескольких специальностей при прочих равных характеристиках, передавать перечень специальностей в одном поле.

Средняя длинна строки в поле 691 - 120 знаков (это соответствует 120 байтам).В базе несколько десятков записей, в которых более 150 связок.
В сумме получаем больше 18 Кб на КО. Но это все многоэкземплярная литература, в которой средняя длинна строки на экземпляр составляет 60 символов, а таких строк может быть и 500-800.
Итог - Ирбис 32 явно предназначен не для ВУЗовских библиотек с большим количеством многоэкземплярной литературы. А Книгообеспеченность в таком случае использовать хоть в сколько-нибудь полной мере невозможно.



Редактировано 1 раз. Последний раз 01.12.2009 11:48 пользователем Gena.

Нет, такие варианты (с повторением данных в одном поле) не предусмотрены.
Сокращенный вариант предполагает пропуск ЭД, используемого "для всех" (факультетов, специальностей, ВО, ФО), но при этом семестры должны быть введены в отдельных повторениях.

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

Gena, а вы не перейдете на последнюю версию? Ведь вы работаете в версии, где взаимодействуют три вида записей : DISC,VUZ,DUNIK, в последних версиях структура сведена к двум типам: DISC и VUZ.
При корректировки дисциплины по ВСЕМ повторениям контингента (83 с учетом размножения по семестру):
1. корректируются или создаются записи VUZ
2................DUNIK.....................
3. корректируются поля 691 записей IBIS, если вы в АРМе Каталогизатор
4. корректируются поля 69 записей RDR, если вы в АРМе Каталогизатор
Процесс достаточно нагруженный.
А в чем проявилось: "БД посыпалась"?

ochagova написал(а):
-------------------------------------------------------
> Gena, а вы не перейдете на последнюю версию? Ведь
> вы работаете в версии, где взаимодействуют три
> вида записей : DISC,VUZ,DUNIK, в последних версиях
> структура сведена к двум типам: DISC и VUZ.
> При корректировки дисциплины по ВСЕМ повторениям
> контингента (83 с учетом размножения по
> семестру):

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


> 1. корректируются или создаются записи VUZ
> 2................DUNIK.....................
> 3. корректируются поля 691 записей IBIS, если вы в
> АРМе Каталогизатор
> 4. корректируются поля 69 записей RDR, если вы в
> АРМе Каталогизатор
> Процесс достаточно нагруженный.
> А в чем проявилось: "БД посыпалась"?

Проблемы с ЭК проявились в том, что некоторые записи, размер которых перевалил критический, просто пропали. Они не индексируются, до них невозможно достучаться по МФН, однако, когда открываю БД через Редактор ИСО, то по инвентарному номеру можно найти хотябы старый вариант записи и выполнить экспорт/импорт именно этой записи. Посыпавшиеся записи обнаружились при книговыдаче - у читателей книги числятся, а когда они пригли их сдавать, программа сказала что таких записей в ЭК нет. Благо архивы базы у нас делаются каждый день - из бекапа базы данных повыдергивали недостающих записей - это были записи с большим числом экземпляров(несколько сотен экземпляров) и связок КО(где-то до 200-300 связок)

Я как-то уже писал, но пока что без реакции. В ирбис 32 давно надо было встроить автоматическую проверку на размер записи - если она рпиблежается к критическому - выдавать сообщение и блокировать дальнейшее изменение записи. Это же совсем не сложно!