Добрый день, уважаемые разработчики САБ ИРБИС!
Мне непонятны два момента, связанные с глобальной (IrbisGblAdmin), на мой взгляд это недоработка.
1. Почему IrbisGblAdmin не может видеть хотя бы для чтения библиографию логически удалённых записей? Например, для записи во вложении, MFN 8547, считать условие v200:'детали машин' верным, а условие v200:'сказки пушкина' неверным? Соответственно, выполнять или не выполнять что-либо в IF..FI для логически удалённой записи в соответствии с такой логикой.
Редактор форматов и Каталогизатор видят библиографию этой записи (см. вложения) и понимают, что там "детали машин", а не "сказки Пушкина". Логично, чтобы и IrbisGblAdmin точно также видел. Но IrbisGblAdmin пишет "Запись недоступна в БД" (а сделать её доступной для чтения нельзя?).

2. Как я выяснил, оператор UNDEL выполняется некорректно в блоке IF..FI, а именно даже при заведомо ложном условии.
Например, глобальная ниже восстановит логически удалённую запись, хотя, как я понимаю, внутри IF..FI с ложным условием в принципе ничего не должно выполняться.

0
IF
if 1=2 then '1' fi
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
UNDEL
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
ADD
987
XXXXXXXXXXXXXXXXXXX
'test'
XXXXXXXXXXXXXXXXXXX
FI
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX


Возможно перспективе устранение вышеперечисленного?

AZelenov написал(а):
-------------------------------------------------------
> Добрый день, уважаемые разработчики САБ ИРБИС!
> Мне непонятны два момента, связанные с глобальной
> (IrbisGblAdmin), на мой взгляд это недоработка.
> 1. Почему IrbisGblAdmin не может видеть хотя бы
> для чтения библиографию логически удалённых
> записей? Например, для записи во вложении, MFN
> 8547, считать условие v200:'детали машин' верным,
> а условие v200:'сказки пушкина' неверным?
> Соответственно, выполнять или не выполнять
> что-либо в IF..FI для логически удалённой записи в
> соответствии с такой логикой.
> Редактор форматов и Каталогизатор видят
> библиографию этой записи (см. вложения) и
> понимают, что там "детали машин", а не "сказки
> Пушкина". Логично, чтобы и IrbisGblAdmin точно
> также видел. Но IrbisGblAdmin пишет "Запись
> недоступна в БД" (а сделать её доступной для
> чтения нельзя?).
>
> 2. Как я выяснил, оператор UNDEL выполняется
> некорректно в блоке IF..FI, а именно даже при
> заведомо ложном условии.
> Например, глобальная ниже восстановит логически
> удалённую запись, хотя, как я понимаю, внутри
> IF..FI с ложным условием в принципе ничего не
> должно выполняться.
>
> 0
> IF
> if 1=2 then '1' fi
> XXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXX
> UNDEL
> XXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXX
> ADD
> 987
> XXXXXXXXXXXXXXXXXXX
> 'test'
> XXXXXXXXXXXXXXXXXXX
> FI
> XXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXX
>
>
> Возможно перспективе устранение
> вышеперечисленного?
Невозможно.

(И пожалуйста, не направляйте уведомления модератору)

Нигде нет в документации, что UNDEL нельзя выполнять в iF..FI.
И то, что что-то выполняется внутри ложного блока iF..FI, по-моему, нелогично, такого не должно быть.

Вы, видимо, решаете какую-то свою задачу. Нельзя под конкретную задачу менять логику. Логика - удаленная запись не подлежит форматированию, формат на ней НЕ выполняется.
Вы можете изменить свой пример:
UNDEL
//-----т.е. сначала восстановить запись
IF
1=2 then '1' fi
DELR

FI

IF
if 1=1 then '1' fi
ADD
987
XXXXXXXXXXXXXXXXXXX
'test'
XXXXXXXXXXXXXXXXXXX
FI

ochagova написал(а):
-------------------------------------------------------
> Логика -
> удаленная запись не подлежит форматированию,
> формат на ней НЕ выполняется.

Тогда почему формат на ней выполняется в редакторе форматов и в Каталогизаторе?

> Нельзя под конкретную задачу менять логику.

По-моему, тот факт, что ЧТО-ТО выполняется внутри IF..FI с ложным условием при IF, противоречит любой логике.

> Нельзя под конкретную задачу менять логику.

Конкретная задача. Например, мне известно, что я по ошибке удалил записи, в которых автор книги Иванов и название "Детали машин", и ещё что-то с какими-то условиями (например, по полю 907). Предположим, таких записей несколько, например 10. Как я буду их восстанавливать? АРМ "Каталогизатор" позволяет найти удалённые записи только поштучно. Предположим, в БД 10 тысяч логически удалённых записей. Что, я должен все 10 тысяч восстановить, чтобы видеть их библиографию? Или 10 раз тыркаться в Каталогизаторе?


Поэтому было бы удобно, чтобы глобальная корректировка видела библиографию логически удалённых записей и позволяла их восстанавливать или не восстанавливать внутри блока IF..FI в зависимости от условия - формата.



Редактировано 2 раз. Последний раз 24.06.2022 15:25 пользователем AZelenov.

Выполнение команд не может зависеть от того внутри они блока IF-FI или снаружи. Вы предлагаете ФОРМАТИРОВАТЬ удаленную запись так же как обычную? Это приведет к непредсказуемым последствиям, если не сказать к катастрофическим.
Например, задания контроля книговыдачи будут давать ложные протоколы. А в случае подключения корректировки давно удаленные записи будут корректировать другие записи. То же самое и с заданиями контроля АРМа Книгообеспеченность. А сколько еще глобальных заданий, которые запускаются на всю базу!
А если распространить правило - "удаленные форматируем" на все виды форматов, то в таблицы полезут какие-то "странные записи", про которые давно забыли.
А статистика? В ней тоже будут учитываться удаленные?



Редактировано 1 раз. Последний раз 26.06.2022 19:26 пользователем ochagova.

Ваша задача решается легко, я сама это не раз проделывала.
1. В настройке Каталогизатора ставите Этап работы, например UNDEL
2. Выполняете по всей БД задание UNDEL, с автовводои + актуалицация
3. В словаре Технологи ищите термин Дата-UNDEL-login. Это все записи, что вы восстановили. Отбираете
4. Убрать из настройка UNDEL
5. Делаете ваши исследования. Если запись надо оставить, то удаляете из поля 907 код UNDEL56.
6. Еще раз отбираете по Дата-UNDEL-login и выполняете на них DELR



Редактировано 1 раз. Последний раз 27.06.2022 02:21 пользователем ochagova.

Сторонние записи (не текущая) могут правиться в глобальных корректировках только, если к ним есть доступ через ref(l(...)). &uf('7...)' или &uf('J...'). А это всё в качестве аргумента имеет термин БД, т.е. предполагает, что они проиндексированы в словаре. Поэтому туда априори логически удалённые (которые не индексируются и на которые вышеуказанные функции не ссылаются) попасть не могут и никакой катастрофы в БД не вызовут.
> Ваша задача решается легко, я сама это не раз проделывала.
Мне тоже это решение кажется самым очевидным в данной ситуации. Но это очень муторно - переставить Этап работы, отглобалить ВСЮ БД (причём в Каталагизаторе, а не в IrbisGblAdmin'е, как я понимаю, либо в IrbisGblAdmin'е добавлять строчку ADD 907 '^A'&uf('3') '^BZAV^CUNDEL'). Потом снова глобалить БД, удаляя ранее восстановленные.
А не проще ли для IrbisGblAdmin'а ввести правило, что он логически удалённые видит для чтения точно также, как и обычные.

> Выполнение команд не может зависеть от того внутри они блока IF-FI или снаружи
Я с моим опытом работы в программировании предполагаю, что должен зависеть. Для меня это всё равно, если в Delphi написать "if 1=2 then ShowMessage('Hello'); ", сообщение появится.

> Вы предлагаете ФОРМАТИРОВАТЬ удаленную запись так же как обычную? Это приведет к непредсказуемым последствиям, если не сказать к катастрофическим.
Я предлагаю форматировать её как обычную только для чтения и только в IrbisGblAdmin. В этом случае никаких катастрофических последствий быть не должно. На редактирование, а также в словаре БД она учитываться не должна (ЧТО вполне логично, раз она ЛОГИЧЕСКИ исключена из содержимого БД). Актуализация словаря тоже на неё не должна распространяться, в смысле актуализация её библиографии.



Редактировано 1 раз. Последний раз 27.06.2022 14:45 пользователем AZelenov.

AZelenov написал(а):
-------------------------------------------------------
> Сторонние записи (не текущая) могут правиться в
> глобальных корректировках только, если к ним есть
> доступ через ref(l(...)). &uf('7...)' или
> &uf('J...'). А это всё в качестве аргумента имеет
> термин БД, т.е. предполагает, что они
> проиндексированы в словаре. Поэтому туда априори
> логически удалённые (которые не индексируются и на
> которые вышеуказанные функции не ссылаются)
> попасть не могут и никакой катастрофы в БД не
> вызовут.
- Не так. В логически уделенную через &uf('7 и др. попасть нельзя, но легко ИЗ логически удаленной (по-вашему) попасть на любую запись.
Например, из удаленного читателя. перейти на книги, выяснить, что статусы неверные и выдать ложные сообщения в задании контроля. Или из удаленной записи дисциплины попасть на записи контингентов, выяснить, что в них нет дисциплины и добавить ее.

> > Ваша задача решается легко, я сама это не раз
> проделывала.
> Мне тоже это решение кажется самым очевидным в
> данной ситуации. Но это очень муторно -
> переставить Этап работы, отглобалить ВСЮ БД
> (причём в Каталагизаторе, а не в IrbisGblAdmin'е,
> как я понимаю, либо в IrbisGblAdmin'е добавлять
> строчку ADD 907 '^A'&uf('3') '^BZAV^CUNDEL').
> Потом снова глобалить БД, удаляя ранее
> восстановленные.
> А не проще ли для IrbisGblAdmin'а ввести правило,
> что он логически удалённые видит для чтения точно
> также, как и обычные.
- если бы ситуация была штатная, то к определению "муторная" можно было бы прислушаться. Но здесь ситуация другая. Хорошо, что вообще ИРБИС предлагает инструмент.

>
> > Выполнение команд не может зависеть от того
> внутри они блока IF-FI или снаружи
> Я с моим опытом работы в программировании
> предполагаю, что должен зависеть. Для меня это всё
> равно, если в Delphi написать "if 1=2 then
> ShowMessage('Hello'); ", сообщение появится.
>
- чтобы такого не было, удаленные записи не идут на корректировку в глобальной и об этом выдается сообщение

> > Вы предлагаете ФОРМАТИРОВАТЬ удаленную запись
> так же как обычную? Это приведет к непредсказуемым
> последствиям, если не сказать к катастрофическим.
> Я предлагаю форматировать её как обычную только
> для чтения и только в IrbisGblAdmin. В этом случае
> никаких катастрофических последствий быть не
> должно. На редактирование, а также в словаре БД
> она учитываться не должна (ЧТО вполне логично, раз
> она ЛОГИЧЕСКИ исключена из содержимого БД).
> Актуализация словаря тоже на неё не должна
> распространяться, в смысле актуализация её
> библиографии.
- Все глобальные - и админ., и клиент., и автоввод, и списание, и проверка фонда и т.д. и т.п. выполняются единой процедурой, по единой логике.

Я предлагаю вам сдаться.



Редактировано 1 раз. Последний раз 28.06.2022 10:30 пользователем ochagova.

> Не так. В логически уделенную через &uf('7 и др. попасть нельзя, но легко ИЗ логически удаленной (по-вашему) попасть на любую запись.

Людмила Николаевна, возможно что да, Вы правы. Но если БД ещё не актуализирована после удаления записи, и если внутри IF..FI по формату логически удалённой выполняется CORREC или NEWMFN.


> - чтобы такого не было, удаленные записи не идут на корректировку в глобальной и об этом выдается сообщение

За исключением UNDEL, которое выполняется вне зависимости от IF..FI.
В таком случае я считаю что целесообразнее запретить выполнять UNDEL внутри любого IF..FI, с выдачей сообщения. UNDEL должно выполняться изолировано, вне каких-то блоков. А то то факт, что что-то выполняется при ложном условии, вызывает диссонанс и неприятности, если не знаешь, что в IrbisGblAdmin удалённая не форматируется. И я не видел, чтобы про это где-то было сказано в документации по Irbis.
> - Все глобальные - и админ., и клиент., и автоввод, и списание, и проверка фонда и т.д. и т.п. выполняются единой процедурой, по единой логике.

Насчёт автоввода и списания согласен, так и должно быть. А в админе не мешало бы сделать опционально возможность форматировать логически удалённые (эта опция д.б. недоступна при одновременном автовводе). Если БД не актуализирована и глобальная содержит CORREC / NEWMFN, то лучше её в этом режиме не запускать. А если просто логически восстановить запись по условию - формату по библиографии, ничего страшного не будет.

"...целесообразнее запретить выполнять UNDEL внутри любого IF..FI" - но я дала вам вариант, где я запрещаю выполнять UNDEL, если он не первый. Это перекрывает ваше предложение. Вариант будет в D3.

"...А в админе не мешало бы сделать..." - нет, не надо плодить лишние сущности. И без этого предложения все прекрасно можно сделать. Я же предложила заменить ваш исходный вариант на:
UNDEL
//-----т.е. сначала восстановить запись
IF
1=2 then '1' fi
DELR

FI

IF
if 1=1 then '1' fi
ADD
987
XXXXXXXXXXXXXXXXXXX
'test'
XXXXXXXXXXXXXXXXXXX
FI
Чем он вас не устраивает?