Глубокоуважаемая Светлана Михайловна!
Это изложение письма от 25.03.05. К сожалению, мы не получили корректного autoin.gbl, отправленного после указанной даты.
Прошу извинить меня за возможно излишнюю настойчивость, но согласен с проблемами, поставленными в письме Елены Осинцевой(Тема «Признак Готов-Не готов»). Я очень прошу Вас еще раз уделить нам внимание и помочь разобраться с этой проблемой. Версия ИРБИС 2003.1.
Относительно неполучения нами результатов пересылки исправленного autoin.gbl сообщаю два e-mail адреса по которому Вы сможете послать, а мы - принять Ваше сообщение.
sergey_balicky@list.ru - мой адрес;
astulib@agtu.secna.ru - адрес библиотеки.
Еще раз извините за навязчивость. Заранее спасибо.
С уважением Сергей Балицкий. зав отделом БИТ АлтГТУ им. И. И. Ползунова.

Отправила по указанным Вами двум адресам письмо, по первому адресу - очередной возврат, по второму письмо ушло, но ответа пока не получила.

Уважаемые коллеги!
После удаления содержимого 83 поля БД VUZ корректным способом (удаление прошло нормально через поле 1002) будет ли происходить обязательное автоматическое удаление содержимого полей 90 и 69 (либо какого-то одного из них) в БД RDR?
После удаления содержимого 83 поля БД VUZ корректным способом (через поле 1002) будет ли происходить обязательное автоматическое удаление содержимого полz 691 в БД IBIS? У меня почему-то этого не происходит.
Удаление содержимого 83 поля БД VUZ производится для последующего ввода нового значения этого поля. Имеем ИРБИС 2003 версия 1.
Жду Вашего ответа.
sergey_balicky@list.ru - мой адрес;
astulib@agtu.secna.ru - адрес библиотеки.
С уважением Сергей Балицкий АлтГТУ.

Если в поле 1002 в записи DISC БД VUZ записано значение поля 83 со всеми семестрами (через/) или только с частью их, то при сохранении записи выполняются следующие операции:
1. Удаляется поле 83 (или только часть семестров) в записи DISC
2. В БД VUZ удаляются записи DUNIK, соответствующие удаляемому полю 83 (или его части).
3. Из записей студентов БД RDR, соответствующих "связке" (факультет - направление ИЛИ специальность-ВО-ФО-семестр) удаляется соответствующее дисциплине повторение поля 69.
4. Из записи ЭК удаляется повторение поля 691, соответствующее дисциплине и той же "связке".
Непременным условием должно быть следующее: длина "связки" не более 29 символов.
Естественно, записи, подлежащие корректировке во всех этих БД, не должны быть открыты (заблокированы). Как сказано в инструкции, за это ответственность несет Пользователь. Процесс достаточно продолжительный.
PS. В новом АРМе Книгообеспеченность выполняются все те же процессы, но при этом не требуется удаляемое поле 83 переносить в поле 1002, а можно выполнять любую корректировку "по месту". При этом процесс корректировки связанных записей протоколируется, а при неблагоприятном его завершении диагностирутся программно, и установка связей может быть наглядно проведена повторно.

Уважаемая Светлана Михайловна!
Вынужднен еще раз обратиться к Вам. В контексте вышеизложенных сообщений (удаление через поле 1002) у меня происходит следующее:
Удаляется поле 83 в записи DISC.
В БД VUZ удаляются записи DUNIK, соответствующие только последнему значению семестра в удаляемом полю 83 записи DISC. Например, если в исходной записи DISC в поле 83 семестры были указаны 4/8, то происходит логическое удаление только записи DUNIK, соответствующей семестру 8.
Соответствующее поле 69 в соответствующей записи БД RDR и поле 691 в соответствующей записи БД ЭК абсолютно не изменяются.

Я попробовал проанализировать VUZ\AUTOIN.GBL и мне кажется что его фрагмент

«Развертка неповторяющегося 1002 для ^F : ‘/’ в повторяющееся 2002»
ADD
2002
…
…(if &uniform(‘1* … )fi/) else v1002 fi
XXXXXXXX

не работает, как повторяющаяся группа. Независимо от того сколько перечислено значений семестров повторяется ОДИН РАЗ. Возможно я не прав.
Очень жду Вашей помощи и надеюсь на Вас.
С глубокой благодарностью
Сергей Балицкий АлтГТУ.

Светлана Михайловна в н.в. в коммандировке и ответить не может

Глубокоуважаемая Светлана Михайловна!
Очень прошу обратить Ваше внимание на мое письмо от 15-04-05 в данной хронологии. Я очень надеюсь на Ваш ответ.
С уважением
Сергей Балицкий НТБ АлтГТУ.

Выделенный Вами фрагмент работает при условии, что подполе F стоит последним в поле 1002.
Здесь отрабатывает цикл по наличию поля 2932, при этом в каждом цикле из первого повторения этого поля строится соответствующее число полей 2002, после чего 2932#1 удаляется.
Если в поле 83 указаны семестры перечислением через / (без пробелов), то в поле 1002 нужно оставить в том же формате только те семестры, которые должны быть удалены.
Например, в поле 83 ^F1/3/4. Хотим оставить только семестр 3.
В поле 1002 нужно записать ^F1/4 (все остальные подполя из поля 83, кроме готовности, должны также присутствовать)

Глубокоуважаемая Светлана Михайловна!
Я делал все в точности по примеру из Вашего предыдущего ответа.
Например, в поле 83 указано ^F1/3/4. Кроме того в предыдущих полях указано; наименование дисциплины на русском языке: "Инф тех упр перс" (без кавычек), факультет: ИЭФ, специальность (из справочника): 080505. Сохранение этой записи происходит нормально. Генерируются все необходимые записи VUZ и DUNIK. Автоматически создается УНД в поле 83^WИТУП/1.
Хотим оставить только семестр 3.
В поле 1002 я пишу ^WИТУП/1^AИЭФ^C080505^F1/4 . Сохраняю. Логически удаляется ТОЛЬКО ОДНА ЗАПИСЬ DUNIK для СЕМЕСТРА 4:

поле 97 ИТУП/1, поле 3^AИНФ ТЕХ УПР ПЕРС^0ИТУП, специальность: поле 92 ^C080505, факультет поле 93 : ИЭФ, семестр поле 95 : 4. Других изменений нет никаких. Я не могу ничего понять. Вкдь должны удалиться все неоходимые записи DUNIK идля семестра 1, и для семестра 4. Кроме того должны пройти удаления в БД RDR в поле 69. Ничего этого нет. Вся надежда на Вас. ИРБИС 2003 версия 1.
Сергей Балицкий.

Да, все должно быть так, как Вы говорите. Но Вам нужно обновить версию.
Вышлю Вам актуальные autoin.gbl для БД VUZ и RDR и RDR.FST (выставлялись в свое время в обновлениях версий).
Не забыли ли Вы обновить format32.dll (c открытого ftp) ?

Глубокоуважаемая Светлана Михайловна!
Спасибо за помощь. Я установил все, присланные Вами, компоненты. Кое-что получилось, но не все. Ввод и удаление записей DUNIK из БД VUZ происходит нормально, как положено по документации. Но, к сожалению, появились проблемы с БД RDR. Не выполняется ни автоматическое, ни ручное занесение 910 поля в запись DUNIK при занесении глобальной корректировкой KUPL.GBL в БД RDR сведений о судентах в 90 поле - Студент ВУЗа. 90 поле Студент ВУЗа заполняется нормально, но никак не удается заполнить поле 69 Кафедра - дисцмплина. Это же поле не улается заполнить также ВРУЧНУЮ. Данные заносятся в 69^d выбором связки УНД - СЕместр (ИТУП/1- S 8). Появляется полное наименование дисциплины в этом поле, эти данные отображаются во всем 69 поле, но при нажатии кнопки "Сохранить" это 69 поле ОПУСТОШАЕТСЯ. Видимо так быть не должно. Я опять надеюсь на Вас.
С уважением С Балицкий.

Да, при сохранении записи студента поле 69 сначала очищается, а затем формируется заново путем переноса данных из соответствующей записи VUZ БД VUZ.
Проверьте наличие записи VUZ в БД VUZ ("связка" фак-напр/спец-ВО-ФО-семестр), соответствующей полю 90 в записи студента. Проверьте длину "связки". Общее число символов в ней, включая два служебных (-S) перед семестром, не должно превышать 29.
Это можно проверить по словарю "свертка ТУД" БД RDR. Посмотрите и убедитесь, что "свертка" показывается полностью, включая семестр (не обрывается).

Глубокоуважаемая Светлана Михайловна!
После выполнения KUPL.GBL и просмотра по словарю "свертка ТУД" БД RDR у меня получилась такая связка: ИЭФ080500080505спцд/о-S4. Ее длина меньше 29. Эта связка нормально разнесена по подполям поля 90. Но поле 69 при этом совершенно ПУСТОЕ. В случае попытки ручного ввода необходимых данных в это поле, эти данные отображаются во всем 69 поле, но при нажатии кнопки "Сохранить" это 69 поле ОПУСТОШАЕТСЯ. Почему оно опустошается во всех случаях мне не ясно или я делаю что не так?
Сергей Балицкий.

А в БД VUZ есть соответствующая запись типа VUZ?

Светлана Михайловна!

У нас та же история с частью записей (правда их немного). В БД RDR из 88 записей студентов одной специальности и одного семестра , у 40 , даже при наличии семестра поле 69 не заполняется и , более того, исчезает после сохранения при ручном вводе. При копировании таких записей в другой mfn всё остаётся по прежнему. И только когда такую запись вводишь по новой, в ручную, тогда всё встаёт на свои места.

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

^EД10-3^AДСФ^C291000^02004/2005^F1010

когда совсем убираешь семестр, оставляя только метку ^F, тоже самое – автоматически семестр появляется сам, но в просмотре всё равно два семестра:

Коновалов Дмитрий Сергеевич (м)
Фак. ДСФ Гр.Д10-4 Сем. 1010

Это только у части из 40 записей происходит.
Да, и в двух версиях: 2003.2 и 2004.2.

Все БД проверялись на блокировки и диагностировались – всё нормально.

С уважением Булыкина О.Д.

Глуьокоуважаемая Светлана Михайловна!
Да, такая запись есть - она абсолютно корректная.

Фак-Напр-Спец-ВО-ФО-семестр (поле 68): ^AИЭФ^N080500^C080505^Vспц^Oд/о^F4 и
Кафедра-Дисциплина (поле 69): ^DИТУП^WИТУП/1
ИРБИС 2003.1

Сергей Балицкий.

Сергею. Пришлите мне по одной записи из БД RDR и VUZ (vuz), между которыми нет согласования. Сейчас проверила на версии 2003.1 работу с Вашим примером - в запись студента дописываются сведения из записи VUZ (БД VUZ)
То же и НТБ КрасГАСА - пришлите по одной записи - студента и VUZ.

Всем - новый АРМ Книгообеспеченность, реализованный на тех же принципах использования 3-х БД, позволяет определять рассогласования между ними и легко их устранять.

Глубокоуважаемая Светлана Михайловна!
Письмо с вложениями записей VUZ и DUNIK из БД VUZ и записи из БД RDR
отправлено.
С уважением,
Сергей Балицкий.

и наши отправлены.

Для опыта всем заинтересованным. В присланных записях были обнаружены ошибки: в записи студента было введено несколько повторений поля 90; в записях книг в служебных подполях поля 691, формируемых автоматически, были внесены посторонние данные. Устранение этих ошибок (внесенных, по всей вероятности, при работе не по технологии) нормальная связь между записями восстановилась.

Поясню как так получилось(во втором случае, с записями книг) и может быть кто не в курсе, чтоб учли. Некоторые данные мы вводили в поле 691^N – «направление» (это ещё до начала работы по интегрированной технологии), затем из этого подполя всё убрали. Убирали глобальной корректировкой и вручную. Так вот, там где глобальной корректировкой или вручную, открывая вложения и в табличной форме, там служебные поля нормально откорректировались.
А вот когда убирали данные вместе с меткой подполя непосредственно из строки, не открывая вложений и не с помощью F3, то при сохранении данные в служебных полях не корректировались и связка получалась неправильной со всеми вытекающими последствиями. То есть, данные из полей, которые входят в «связку» так корректировать нельзя.