1. В стандартной поставке не предусмотрена возможность указания типа литературы: основная или дополнительная. Я добавил её, создав новое поле в Настройках: «Тип литературы». Для этого потребовалось изменить файл Setprivk.wss и DiscSecCat.fst.

991 0 "^W"v97,"^D"v3^A,"^S"v4,"^B"v5,"^A"v93,"^K"v6,"^V"v96,"^F"v95,"^I"V3^0,"^C"v92^C,"^N"v92^N,"^O"v98,"^H"v94,if &uf('IPRIVATE,A,'):'ДОП' then '^GДоп' else if &uf('IPRIVATE,A,'):'ОСН' then '^GОсн' fi fi

2. Новая связка вставляется в запись только в том случае, если аналогичная связка там отсутствует (^W190/25^DИностранный язык^BИЯ^AФИТСУ^F1^I190^C21010^N651900^Oо^HПУИС). Проводится жесткая сверка по всем подполям, и, следовательно , малейшее изменение в любом подполе приведёт к повторному копированию связки. Поскольку нам пришлось изменить идентификатор дисциплины, такая жесткая проверка была не оправдана. Из файла CHK691.gbl(Move691.gbl) я удалил некоторые условия. Для большинства библиотек таким «динамичным» полем будет, видимо, название дисциплины(Например, начнут читать Философию под названием История философии, а содержание курса останется прежним). Подчеркну, что по интегрированной технологии мы ещё не работам, и к проблемам незначительные расхождения не приведут(потом конечно придётся писать трёхэтажную корректировку).



Отправка отредактированного (09-01-06 18:03)

3. Как я уже замечал(см. ошибка низкого уровня при работе со словарём), в сетевом режиме работать с модулем оказалось невозможно. В связи с этим, пришлось предусмотреть процедуру синхронизации. (автоввод и актуализация для повышения скорости так же отключались) Глобальная корректировка запускается вручную в ЛОКАЛЬНОЙ копии основной базы сотрудника и добавляет сведения в сетевую(NWPIB).

IF
if p(v3703) then, '1',&uf('+1W655#',v3700),&uf('+1W658#',(v691/)) else '0' fi
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
CORREC
'NWPIB'

&uf('+1W653#'),if val(&unifor('JNWPIB,I='v903))>0 then &uf('+1W653#I=',v903) else if &uf('Av3701^b#1')<>'' and &uf('7NWPIB,?IN=',&uf('Av3701^b#1'),'?,"1"d920')='1' then &uf('+1W653#','IN=',&uf('Av3701^b#1')) else (if p(v910^b) then if &uf('7NWPIB,?IN=',v910^b,'?,"1"d920')='1' then &uf('+1W653#IN=',v910^b) fi fi),fi,fi,&uf('+1R653')
XXXXXXXXXXXXXXXXXXX
DEL
691

XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
ADD
691
XXXXXXXXXXXXXXXXXXX
&uf('+1R658')
XXXXXXXXXXXXXXXXXXX
ADD
907
XXXXXXXXXXXXXXXXXXX
'^CКН','^A',&uf('+1R655'),'^BСРБ'
XXXXXXXXXXXXXXXXXXX
END
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
FI
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX

Почему же я не воспользовался здесь модельным полем 1001? ;) Да, да. Всё та же самая проблема переполнения записи. . . .

В CHK691.gbl было добавлено:
DEL
3700

XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
DEL
3703

XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
ADD
3700
XXXXXXXXXXXXXXXXXXX
&uf('3')
XXXXXXXXXXXXXXXXXXX
ADD
3703
XXXXXXXXXXXXXXXXXXX
'СИНХРОНИЗИРУЕМ'
XXXXXXXXXXXXXXXXXXX

В версии 5.2:
1. В задании Move691 предусмотрено задание через WSS опроса признака основная/дополнителная, который вписывается в поле 691
2. Есть пакетное задание на изменение имени дисциплины во всех связанных записях. В вашем варианте то же самое - при изменении имени дисциплины и выполнении связей
Вы приписку данных в записи каталога делаете через перенос? Если да, то чем, вы думаете, ваше задание на синхронизацию быстрее и лучше чем аналогичное (даже проще) задание на перенос Move691?

Очагова Л.Н. писал(а):

> В версии 5.2:
> 1. В задании Move691 предусмотрено задание через WSS опроса
> признака основная/дополнителная, который вписывается в поле
> 691

Версии 2005.2 пока не существует, но то, что это предусмотрено - хорошо. Проблема в том, что мы вынуждены не только ждать новых версий, но ещё и работать со старыми.

> Вы приписку данных в записи каталога делаете через перенос?
> Если да, то чем, вы думаете, ваше задание на синхронизацию
> быстрее и лучше чем аналогичное (даже проще) задание на перенос
> Move691?

1. Должен заметить, что наш подход сильно отличается. Я определяю результат работы собственных «творений» ещё до того, как предложить их для использования, а вы, видимо, предпочитаете делать это после. ;) Естественно, синхронизация с базой производится независимо от добавления сведений по книгообеспеченности и осуществляется приблизительно раз в неделю, вместе с обновлением локальной базы.
2. Да, возможно оно быстрее. Быстрее потому, что работает с полем целиком, а не с каждым повторением в отдельности.

Кстати, мне кажется, этих уточнений я мог быть не делать: принцип работы нашей технологии был ясен из того, что я уже писал. « Глобальная корректировка запускается вручную в ЛОКАЛЬНОЙ копии основной базы сотрудника и добавляет сведения в сетевую(NWPIB).».

> 2. Есть пакетное задание на изменение имени дисциплины во
> всех связанных записях. В вашем варианте то же самое - при
> изменении имени дисциплины и выполнении связей

Да, это очень полезная функция нового модуля. Тем не менее, если я заливаю вместо одной базы учебного отдела другую, едва она едва ли может помочь. В моём случае константы - это: 1) Идентификатор дисциплины 2) Специальность 3) Семестр 4) Форма обучения. Этих данных хватает для проверки связок на «дублетность». Естественно, что я уже готовлюсь писать трёхэтажную корректировку, перед тем как начать работу по интегрированной технологии.

Вы получили мои записи? Если да, то:
1. В случае с Комплектатором вы подтверждаете наличие ошибки в программе?
2. В случае с Книгообеспеченностью вы подтверждаете потенциальный риск переполнения?
3. В случае с переносом данных, вы подтверждаете факт длительных задержек?
С 16 записями, которые я прислал вам отдельно, попробуйте заново создать словарь со стандартным ТВП. Что получается? Ошибка и переполнение, хотя до стандартных 32 килобайт далеко. И если у вас возникают сомнения, что переполнение касается других библиотек, то посмотрите сообщения по этому поводу : [irbis.gpntb.ru]. Как видите, игнорировать эту проблему больше нельзя

PS
Светлана Михайловна так и не ответила на мой вопрос относительно того, встроена ли поддержка сокращённого варианта в модуль или нет. Мне представляется, что она ошиблась, или я не прав?



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

1. Арм Комплектатор. Еще раз можно описать ситуацию: какая БД, какой словарь, "При попытке вставить данные, связанные с термином(щелчок мышью) выдаётся - List index out of bounds(0). " - где вы вставляете данные (в модуле корректировки?), в какую запись, в какое поле.
2. Риск переполнения. Предположим вы ввели в поле 691 20 повторений (неужели бывает много больше?), в каждом 100 знаков. Это дает добавку в записи примерно 2К. При максимуме 32К это не так уж много.
3. Согласна, что процесс переноса в записи каталога занимает время. Но это, фактически, работает глобальная. Т.к. это выполняется не программно, то с этим приходится мириться. Я думаю, что наполнение записей каталога дисциплинами делается не так уж часто.

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

Ваши БД не дошли. Если вы собирались прислать всего 16 записей, то на мой адрес: ochagova@yandex.ru.

Очагова Л.Н. писал(а):

> 1. Арм Комплектатор. Еще раз можно описать ситуацию: какая
> БД, какой словарь, "При попытке вставить данные, связанные с
> термином(щелчок мышью) выдаётся - List index out of bounds(0).
> " - где вы вставляете данные (в модуле корректировки?), в какую
> запись, в какое поле.
> Ваши БД не дошли. Если вы собирались прислать всего 16
> записей, то на мой адрес: ochagova@yandex.ru.

Послал теперь и на ваш ящик; всё необходимое в комплекте.

> 2. Риск переполнения. Предположим вы ввели в поле 691 20
> повторений (неужели бывает много больше?), в каждом 100 знаков.
> Это дает добавку в записи примерно 2К. При максимуме 32К это не
> так уж много.

Я назвал точные данные по количеству связок в нашем случае:
Физика - 247 связок
Высшая математика - 346
Иностранный язык - 403

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

Я привёл ссылку на аналогичную жалобу со стороны представителей другой библиотеки.
[irbis.gpntb.ru]

Неужели этих аргументов недостаточно?

В Петербурге, если мне не изменяет память с ИРБИС работает около 50 библиотек. Большая часть из них ВУЗы. Вы можете указать хоть одну библиотеку, которая использует новый модуль(или хотя бы просто интегрированную технологию) и у которой «всё в порядке»?

Книгообеспеченностью просто не пользовались, или задействовали её частично(никто конечно об этом не распространялся), поэтому до сих пор сообщений о проблемах было не слишком много. Поверьте, как только ВУЗы начнут серьёзно с ней работать, я буду не единственным, кому «что-то не нравится».

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

Мириться можно с тем, что неизбежно и имеет какие-то объяснения. Единственной причиной столь продолжительной работы приложения может быть его фантастическая кривизна. Хорошо, что вставка делается не приложением, а форматом(с этим можно смириться, поскольку ошибки исправить легче), но зачем нужны обращения с словарю и DUNIC, когда при помощи формата можно легко и просто получать те же данные из DISC?

Посмотрим на сам формат переноса. Если проиллюстрировать его работу наглядным примером, то можно сравнить его с сумасшедшим библиотекарем, который пересчитывая книжки на полке, подсчитав новую книжку начинает считать сначала:
Один
Один, два
Один, два, три
Один, два, три, четыре
Один, два, три, четыре, пять

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

> Я
> думаю, что наполнение записей каталога дисциплинами делается не
> так уж часто.

У нас на этом сидел один сотрудник(слава богу, теперь он занимается и другой работой). Методички идут постоянно. В сетевом режиме было так: он включал перенос сведений, уходил и в сетевом режиме оставлял это на ночь, а на утро он приходил и не мог работать - данные ещё небыли перенесены. . . . .

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


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

> Кстати, замедление в каком-то процессе может быть связано с
> тем, что вы неправильно написали формат, в нем зацикливание,
> форматер ошибку не даст, но цикл будет вып-ся 5000 раз (стоит
> ограничение).

О глобальной корректировке мне давно хотелось написать поэму, но не доходили руки. Можно вообще поинтересоваться, с какой целью введено это ограничение: чтобы существующую ошибку никто и никогда не нашел? Кроме того, мне кажется, вы добавили лишний ноль: в 2004.2 стоит ограничение на 500 циклов. Вы даже не представляете, какие проблемы мне создало это ограничение, и сколько времени я угробил на преодоление этих проблем...

Как сделать чтоб на подплоскости "ЗАКАЗЫ" была возможность открытия полнотекстового документа? Аналогично кнопке "Полный текст" на АРМах каталогизатор или читатель.

Кириллу Соколинскому.
1. АРМ Комплектатор - я выслала по почте
2. Перенос - согласна, что при переносе много отмеченных они друг друга проверяют на дубль, хотя в них дублей нет. Это можно оптимизировать. Но все же - не может столько идти это безобидное задание. Как же у вас тогда работают более крутые глобальные? Мне непонятна фраза "зачем нужны обращения с словарю и DUNIC" - перенос идет из записей DUNIC, при чем тут DISC. Чтобы не было несовпадений привожу текст задания на перенос
1
691g.mnu
ВВЕДИТЕ признак основная/дополнительная
// перенос из DUNIK данных в запись каталога 691
DEFFLD
3000
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
DEL
4000

XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
IF
if a(v691) then '1' else if rsum((if p(v691) then if v691^W=&unifor('Av991^W#1') and v691^D=&unifor('Av991^D#1') and v691^S=&unifor('Av991^S#1') and v691^B=&unifor('Av991^B#1') and v691^A=&unifor('Av991^A#1') and v691^K=&unifor('Av991^K#1') and v691^V=&unifor('Av991^V#1') and v691^F=&unifor('Av991^F#1') and v691^I=&unifor('Av991^I#1') and v691^C=&unifor('Av991^C#1') and v691^N=&unifor('Av991^N#1') and v691^O=&unifor('Av991^O#1') and v691^H=&unifor('Av991^H#1') then '1,' else '0,' fi fi))>0 then '0' else '1' fi fi
ADD
691

&unifor('Av991#1'),if v992<>'' then '^G',v992 fi

PUTFLD
'Откорректирована запись. MFN=',f(val(mfn),0,0)
FI
DEL
991
*


DEL
992
*


GETFLD
4000
3. По поводу ограничений форматера - специально посмотрела: кол-во проходов повторяющейся группы 1000. Ограничение мы вынуждены были ввести, т.к. иначе эта ошибка (бесконечный цикл) приводила к зависаню, а теперь код 57. Какие же у вас с этим были проблемы?
4. Тестирование АРМа КО. Для меня полигоном является библиотека Тимирязевки. Но буду рада, если вы в своей библиотеке будете тестировать и слать замечания. Только надо брать последнюю версию, я ее вскоре поставлю на FTP.

Просмотр полного текста в АРМе Комплектатор не предусмотрен.

<Светлана Михайловна так и не ответила на мой вопрос относительно того, встроена ли поддержка сокращённого варианта в модуль или нет. Мне представляется, что она ошиблась, или я не прав?>

Я отвечала Вам 22.12.2005 в теме "Ошибка низкого уровня"

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

Очагова Л.Н. писал(а):

> Кириллу Соколинскому.
> 1. АРМ Комплектатор - я выслала по почте

Большое спасибо!

> 2. Перенос - согласна, что при переносе много отмеченных они
> друг друга проверяют на дубль, хотя в них дублей нет. Это можно
> оптимизировать.

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

> IF
> if a(v691) then '1' else if rsum((if p(v691) then if

Если поле v691 является пустым, то проверка на дублетность не осуществляется. Да, в первый раз мы имеем выигрыш в скорости.

> v691^N=&unifor('Av991^N#1') and v691^O=&unifor('Av991^O#1') and
> v691^H=&unifor('Av991^H#1') then '1,' else '0,' fi fi))>0 then
> '0' else '1' fi fi

Добавляем новую связку. И поле v691 уже перестаёт быть пустым.

> ADD
> 691
> &unifor('Av991#1'),if v992<>'' then '^G',v992 fi

Теперь, когда мы работаем со второй вставляемой связкой, то a(v691)=false. Следовательно, будет осуществляться проверка на дублетность с первой, только что вставленной связкой. После вставки второй, третья будет проверяться на дублетность с первой и второй и так далее. Я просто ничего не понимаю. . .

Единственным корректным способом был бы вариант при котором:

1.Оригинальные(не дублетные) значения v991 аккумулировались бы в глобальной переменной(если конечно её значение не очищается. . . ).
. . . . v691^H=&unifor('Av991^H#1') then &uf(‘+1W444#’,&uf(‘+1R444’), &uf('Av991#1') # ) else '0,' fi fi))>0 . . . .

2.А затем ОДНОКРАТНО вставлялись бы в запись.
Это полностью устранит проблемы с продолжительной монопольной блокировкой и подписаниями других пользователей базы!

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

> 3. По поводу ограничений форматера - специально посмотрела:
> кол-во проходов повторяющейся группы 1000. Ограничение мы
> вынуждены были ввести, т.к. иначе эта ошибка (бесконечный цикл)
> приводила к зависаню, а теперь код 57. Какие же у вас с этим
> были проблемы?

Прошу прощения, я не верно вас понял: я говорил о циклах(REPEAT UNTIL) в глобальной корректировке.

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

Кстати, как я понимаю, в вашем модуле тоже используется доморощенный форматер, выполненный под редакцией Н. Мазова? Хочется верить, что у вас выражение f(0, 0, 0) не будет возвращать 0, как в WEB IRBIS (см.: Веб-64. Формирование ссылок "Далее").

> 4. Тестирование АРМа КО. Для меня полигоном является
> библиотека Тимирязевки. Но буду рада, если вы в своей
> библиотеке будете тестировать и слать замечания. Только надо
> брать последнюю версию, я ее вскоре поставлю на FTP.

С радостью готов. Всё равно приходится и тестировать и писать о проблемах.

> Но все же - не может столько идти это
> безобидное задание.

Я ещё раз подчёркиваю, что несмотря на двойную сверку на дублетность, эта глобальная корректировка незначительно увеличивает время вставки. Время вставки определяется главным образом алгоритмом исполняемого модуля, принцип работы которого я понять не могу. Не могу объяснить себе, почему продолжительность вставки каждой новой связки возрастает в арифметической прогрессии.

Наша база VUZ занимает в архиве 650 килобайт. Может быть её можно послать вам на тот же ящик? Это сняло бы все вопросы.

> Как же у вас тогда работают более крутые
> глобальные?

Вот об этом я как-нибудь напишу отдельно. Но всё таки работают лучше.

> Мне непонятна фраза "зачем нужны обращения с
> словарю и DUNIC" - перенос идет из записей DUNIC, при чем тут
> DISC. Чтобы не было несовпадений привожу текст задания на
> перенос

Запись DISC является родовой для записей типа DUNIK и VUZ. Обрабатываясь соответствующим алгоритмом, она порождает DUNIK и VUZ. В ней содержится тот же объём информации, что и них. При работе с Каталогизатором достаточно сложно использовать информацию из DISC, т. е. нужным образом преобразовать и вставить в виде связки, но, модуль Книгообеспеченность предназначен для этого!
Как мне представляется, наиболее продолжительным процессом является поиск нужной связки(записи DUNIK) в словаре, обращение к ней и её вставка. Этих задержек вполне можно избежать, если осуществлять поиск по словарю только 1 раз - для получения записи DISC, обработать её нужным образом, и вставлять ВСЕ необходимые связки ОДНОВРЕМЕННО.
Я понимаю, что для этого придётся радикальным образом переделывать многие функции модуля Книгообеспеченность. Но этого всё равно не избежать. . .

Между прочим, я писал об этом раньше:
> Почему при вставке данных в библиографическое описание DISC
> оказывается недостаточно? Обрабатываясь тем же алгоритмом,
> посредствам которого генерируются DUINC,
> разве она не может дать все необходимые сведения?



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

Дунаевская С.М. писал(а):
> Я отвечала Вам 22.12.2005 в теме "Ошибка низкого уровня"

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

> Правда, о необходимости обязательного использования
> БД RDR я сказала зря - работа возможна по обоим вариантам

Это очень хорошо.

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

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

> Как сделать чтоб на подплоскости "ЗАКАЗЫ" была возможность
> открытия полнотекстового документа? Аналогично кнопке
> "Полный текст" на АРМах каталогизатор или читатель.

Это можно реализовать в формате просмотра при помощи функции &unifor('+I. В нашем случае это выглядит так:

if p(v3540) then,'\tab \tab ',&uf('+I?0,,U:\\Методички\\'v3540'.pdf?','(Имеется электронная версия)','') ,'\par' fi,

Поле v3540 - название электронного документа. В вашем случае U:\\Методички\\'v3540'.pdf’, видимо, нужно заменить на что-то вроде v951^i,v951^a.

1. Перенос. На счет оптимизации переноса я только предположила, но еще не сделала.
2. Форматер. Уточняю - он был написан незабываемым Дель Биджио, потом редактировался Мазовым, а теперь редактируется нами.
3. Пернос. Вы писали "...поиск по словарю только 1 раз - для получения записи DISC, обработать её нужным образом, и вставлять ВСЕ необходимые связки ОДНОВРЕМЕННО". Может я вас не поняла, но
- поиск никакой не нужен, т.к. записи DUNIK сразу отображаются в связанном окне. Из них и переносим.
- как можно переносить из DISC, если там данные в 83 скумулированы по семестрам
- еще раз просмотрела вариант сокращенных связей в АРМе КО. Он работает. В записи DISC заводите это сокращенное повторение (напр. только семестр) и далее по технологии. Все связи формируются.

Очагова Л.Н. писал(а):

> 2. Форматер. Уточняю - он был написан незабываемым Дель
> Биджио, потом редактировался Мазовым, а теперь редактируется
> нами.

Скажите, его код находится в каждом из программных модулей, или он зашит в библиотеку FORMAT32.DLL ?

> 3. Пернос. Вы писали "...поиск по словарю только 1 раз - для
> получения записи DISC, обработать её нужным образом, и
> вставлять ВСЕ необходимые связки ОДНОВРЕМЕННО". Может я вас не
> поняла, но
> - поиск никакой не нужен, т.к. записи DUNIK сразу
> отображаются в связанном окне. Из них и переносим.

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

Но, два других вопроса остаются:
1. ЧТО является причиной ПРОГРЕССИРУЮЩИХ задержек при вставке(использования режима вставки) каждой новой связки, даже при удалении всех операторов из CHK691.gbl?
2. Почему нельзя сделать так, чтобы отобранные(не дублетные) записи(связки) аккумулировались и затем ОДНОКРАТНО вставлялся в запись?

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

Тогда я решительно не понимаю Светлану Михайловну. Я задавал вопрос:

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

И получил от неё ответ:

> Сокращённый вариант не требует изменений в базе VUZ.

1. Код форматера зашит в format32.dll
2. Задержки. Может у вас работает autoin.gbl вместо autoink.gbl? В нем (autoink) убраны все обработкаи, которые перенесены в разные пакетные задания, и он должен работать быстро.
3. Аккумуляцию в move691 я сделаю.
4. Сокращенные связки надо вставлять в запись DISC, чтобы на них формировались записи типа VUZ и DUNIK, из которых можно делать перенос. Может С.М. еще прокоментирует это.
5. На открытый FTP я поставили install_KO версии 5.2. Буду рада, если вы потестируете. Обратите внимание на режим удаления - кнопка в окне переноса. И на пакетные режимы изменения записей.

Очагова Л.Н. писал(а):

> 2. Задержки. Может у вас работает autoin.gbl вместо
> autoink.gbl? В нем (autoink) убраны все обработкаи, которые
> перенесены в разные пакетные задания, и он должен работать
> быстро.

Autoin и Autoink просто удалены, fst базы очищен. Об этом я уже писал.
Сейчас вновь повторил все свои эксперименты. Пришел к выводу, что дело всё-таки в Move691.gbl. После удаления алгоритма отбора, прогрессирующая задержка сохранялась(длительность конечно уменьшилась), но она исчезла после удаления операторов ввода.

Вы писали, что «GETFLD - пишет то, что записано во временном поле в реальное поле записи, метка которого во второй строке.», но с какой целью он используется в данном случае, куда и какое значение он записывает?

«4. Сокращенные связки надо вставлять в запись DISC, чтобы на них формировались записи типа VUZ и DUNIK, из которых можно делать перенос. Может С.М. еще прокоментирует это.»
Было бы логично, если бы сокращённые связки генерировались новым модулем автоматически, при выделении всех связок дисциплины на левой панели.

Поскольку я не уверен, что через alio@gpntb.ru вам удаться получить мою базу, я решил послать одну запись на ваш ящик. Работа с ней без труда позволит выявить все имеющиеся проблемы.

<Может С.М. еще прокоментирует это.>
Когда я говорила, что БД VUZ не требует изменений, я имела ввиду, что ввод по сокращенному варианту не требует никаких программных и форматных доработок, но вводить данные, естественно, нужно явно по сокращенному варианту.
Наверное, такие записи можно "укоротить" глобальной корректурой, а через новый АРМ и с корректировкой связанных записей.

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

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

Уточните пожалуйста, каким образом это возможно.

По поводу новой версии модуля. Небольшие ошибки, на которые хотелось бы обратить внимание:
1.При отсутствии выделенных записей выдаётся вопрос "Не отмечены данные для переноса. Переносить всё" После нажатия кнопки "Да", все записи, однако, не переносятся. Появляется сообщение "нет сообщений об изменении записей"
2. Перенос допускает отмену кнопкой Возврат, но на практике, после её нажатия только удаляется информационное окно: перенос продолжается.


Ещё раз хотелось бы обратить ваше внимание на алогичный механизм отбора БО для переноса сведений по книгообеспеченности(правая панель). То, что двойной щелочек приводит к открытию формата показа с первым БО на термине - ненормально. Представьте себе продавца в магазине, который в ответ на вашу просьбу показать книги по определённому предмету, снимает с полки только одну книгу - ту, которая к нему ближе. Разве это не раздражило бы вас?

Если бы откорректировать обработку события было бы сложно, я не стал об этом писать. Но сделать это элементарно, а работа с модулем сильно облегчилась бы. О кнопке Просмотр записей я знаю. До неё нужно далеко тянутся и нашим сотрудникам тяжело в неё попадать. :)

Спасибо за замечания 1,2. Сделала отметку обязательной, без возможности переносить ВСЕ.
"То, что двойной щелочек приводит к открытию формата показа с первым БО на термине - ненормально." - а какие действия вам кажутся более логичными? Если есть отмеченные, то их (всей группы) просмотр по кнопке, а двойной щелчок - только для текущей, независимо от отметок. Разве это не логично?
На FTP я обновила install_KO - добавила удаление контингента, пакетное отчисление/восстановление студентов.

Очагова Л.Н. писал(а):

> "То, что двойной щелочек приводит к открытию формата показа с
> первым БО на термине - ненормально." - а какие действия вам
> кажутся более логичными? Если есть отмеченные, то их (всей
> группы) просмотр по кнопке, а двойной щелчок - только для
> текущей, независимо от отметок. Разве это не логично?

1. Двойной щелчок на ТЕРМИНЕ словаря должен предоставлять возможность ОТБОРА конкретных записей, связанных с этим термином.

2. Двойной щелчок на записи в режиме отбора должен приводить к просмотру этой записи целиком.(что и происходит)

3. Чекбокс напротив термина должен приводить к отбору ВСЕХ записей связанных с термином.(что и происходит)