Здравствуйте. Работаем на Ирбис-32 2005.2. При сохранении изменений в АРМ Книгообеспеченность программа "задумывается" в среднем на полчаса, либо вообще зависает. Пробовали работать с сервера, результат не многим лучше. Размер БД VUZ 3500 записей, RDR 15000, книг 23000 записей. Вариант с обновлением версии не предлагать.

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

Возможно. Сеть на основе университетского домена и с разграничением доступа творятся странные вещи. Решаем.
Пробовали запускать удаленный рабочий стол, в основном это почему-то приводит к блокировке БД RDR и полному зависанию программы. Кроме всего прочего при запуске на сервере Irbisk.exe "съедает" все время процессора пока производит сохранение, как результат сервер в это время почти не может обрабатывать сетевые запросы.
Появилась идея установить на отдельной машине Ирбис, с пустыми БД читателей и книг, чисто для редакции VUZ, а потом подгрузить её в реально действующую. Вот только равносильными ли будут корректировки проводимые Irbisk.exe и при импорте VUZ?

На момент создания базы Вуз у нас тоже были проблемы с сетью. Именно так мы и поступили. На машине, за которой работал оператор по созданию БД ВУЗ установили Ирбис, в котором из баз были только Ибис и Вуз, весь процес СОЗДАНИЯ прошол на одной машине отдельно от основной программы. После того, как эта работа была завершена, просто перенесли все из одной программы в другую.
Но все равно в последствии пришлось работать с Удаленным рабочим окном при привязывании к книгам соответствующих контингентов. Единственное что нас в этой ситуации выручает, так это то, что наш сервер двухядерный - при любом сложном действии Ирбис загружает только одно ядро, а второе может в это время выполнять все оставшиеся функции.

Источник зависания - либо автоввод записи, либо актуализация записи. Попробуйте сначала отключить автоввод, т.е. в файле irbisk.ini сделайте autoin=. Т.е. пусто. Напишите о результатах.

Ой... а при этом не перестанут формироваться связи и происходить все необходимые процессы? Завтра поэксперементируем...

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

Цитата:

Вера Тарасова
При сохранении изменений в АРМ Книгообеспеченность программа "задумывается" в среднем на полчаса, либо вообще зависает.

После многих экспериментов могу сказать, что главной причиной длительного сохранения записей базы каталога является актуализация. В последней версии модуля Книгообеспеченность ввод и отбор данных в библиографические записи происходит очень быстро, а сетевая актуализация занимает, вероятно, в 100 раз больше времени. Вы можете проверить так ли это в Вашем случае, добавив в секцию [Entry] INI файла модуля параметр RECUPDIF=0

Проблема длительной актуализации в целом характерна для ИРБИС 32, но мне кажется, что при работе с Книгообеспеченностью вариантов решения больше, чем в случае с другими модулями.

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

Правда отключение актуализации в самом модуле может усложнить работу с базой VUZ и базой читателей. Ведь там актуализация – неотъемлемое условие адекватной корректировки связанных данных. И я вижу только один выход – при внесении данных в БЗ пользоваться ИНИ файлом с отключённой актуализацией, а при работе с VUZ и RDR INI с включённой актуализацией. Но конечно оптимальным решением была бы возможность отключать и включать актуализацию для отдельных баз.

Я упустил ещё один способ ускорения работы Книгообеспеченность 32, который достаточно давно применяется у нас – перемещение базы VUZ на локальный компьютер. Сделать это очень просто – нужно только изменить пути в файле VUZ.PAR, указав в каждой строчке абсолютный путь к папке с локальной базой.

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