посмотрела - результаты поиска, найденная книги либо журнал, либо список книг имеют www адрес с расширением в конце .exe.

Те прямую ссылку на издание в web сделать нельзя.

Посмотрела в демо-версии в ИРБИС64+ тоже также результат поиска в конце .exe

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

Все сводные описания журналов имеют на конце расширение .exe - те ссылку на них я не могу указать никак?

Некоторые книги при повторном поиске открываются по огромной ссылке.
[librarynew.gpntb.ru]
Но если книг более 1, список не откроется.
и первоначальный поиск тоже.

Все можно сделать.

Пример прямой ссылки на документ по полю 903:

[library.pgups.ru]

NataliT написал(а):
-------------------------------------------------------
> Посмотрела в демо-версии в ИРБИС64+ тоже также
> результат поиска в конце .exe
>
> Те получается нельзя вставить ссылку на издание ни
> в рабочую программу дисциплины, ни отправить
> результат поиска по эл.почте?

Проблемы с предоставлением ссылок не существует. Но длинна адреса может быть преодолена только квалифицированным системным администратором.

>
> Все сводные описания журналов имеют на конце
> расширение .exe - те ссылку на них я не могу
> указать никак?

Пример ссылки с идентификацией по 903 полю был приведён в предшествующем сообщении. Если исправить ошибку -- убрать символ усечения ($), то на ссылку можно ориентироваться.

Но наиболее корректной является идентификация по DOI. Это позволит несколько сократить идентификатор за счёт устранения кириллицы.

h ttp://libname.ru/cgi-bin/irbis64r_XX/cgiirbis_64.exe?C21COM=S&I21DBN=IBIS&P21DBN=IBIS&S21FMT=fullwebr&S21ALL=<.>B=DOI [значение DOI]<.>



Редактировано 1 раз. Последний раз 25.04.2018 14:26 пользователем Кирилл Соколинский (СЗТУ).

Написать постоянный запрос в короткой форме не так сложно и даже проще ручками.
Вот пример запроса на ключевом слове "Детская литература" на нашем каталоге. (В слове http пробел стоит для отображения здесь на форуме!)

h ttp://www.library.tomsk.ru/cgi-bin/irbis64r_14/cgiirbis_64.exe?C21COM=S&I21DBN=MILS&P21DBN=MILS&S21ALL=(<.>K=детская%20литература<.>)

Добрый день!
ИРБИС64+
Мне нужно давать ссылки на тексты (или библиографические записи) давать. Выше приводиться пример ссылки DOI. А куда вводиться DOI в библ. записи?

посмотрите поле 19
19^A тип номера - 6 DOI (Идентификатор цифрового объекта)
19^b сам номер

в поиск попадает по префиксу B=
(|B=|d19,v19^a*2| |,v19^b,|%|d19/)
т.е будет B=DOI сам_номер (из поля 19^b)

Государственная универсальная научная библиотека Красноярского края, Ассоциация ЭБНИТ

Спасибо!
Все работает. У меня получилась такая ссылка:
cgi-bin/irbis64r_plus/cgiirbis_64_ft.exe?C21COM=S&I21DBN=SFI_FULLTEXT&P21DBN=SFI&S21FMT=briefHTML_ft&Z21ID=GUEST&S21ALL=<.>=DOI 123456<.>

Коллеги, добрый вечер. Подскажите пожалуйста. Тоже нужно делать ссылки на конкретную запись ЭК. По DOI в веб-ирбисе вроде всё получилось, на запись по ссылке переходит.
Я правильно поняла, что значение в поле 19^b можно ставить любое?
Тогда вопрос - в каталогизаторе появилась ссылка "Переход по DOI" и соответственно при нажатии она переходит на сайт [dx.doi.org] и пишет "DOI Not Found". Или тут ещё какая-то хитрость?

А значение DOI вы как заполняете? Вручную или какой-то глобальной корректировкой?

И насколько корректно использовать DOI для идентификации документа внутри базы? Как я понял, DOI это глобальный сервис, в котором документ получает уникальный идентификатор по всему миру и надо регистрироваться в сервисе doi.org чтобы ссылка «Переход по DOI» работала.

--
Сергей Кузнецов

elkinaos написал(а):
-------------------------------------------------------
> Я правильно поняла, что значение в поле 19^b можно
> ставить любое?

Правильный DOI имеет особый формат.


--
Сергей Кузнецов



Редактировано 1 раз. Последний раз 19.05.2020 16:57 пользователем Grievous.

Оказывается в Ирбис64+ 2018 каждой записи в базе уже при создании присваивается уникальный GUID, но хранится он в скрытом поле, которое мы не видим напрямую, но можем прочитать через команду &uf('+*')
GUID постоянен и не меняется, в отличии например от MFN. И доступен для поиска через словарь GUID=
Предлагаю простое решение для постоянной ссылки. Этот кусочек кода вставить в конец карточки (файл …\Deposit\fullwebr.pft)

'<A title="Постоянная во времени гиперссылка на этот интересный документ — можете пересылать её друзьям" HREF="',
&uf('IWEB,CGI_ALIAS,'),
'?I21DBN=',&uf('Av2221#1'),
'&P21DBN=',&uf('Av3331#1'),
'&C21COM=S',
'&S21P03=GUID=',
'&S21STR='&uf('+*'),
'">Ссылка на документ</a>',

--
Сергей Кузнецов

А в чем преимущество по сравнению с 903-м полем?

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

Если 903-е поле может меняться (а ИРБИС позволяет это), то преимущество в неизменности GUID.

С другой стороны, если, в нарушение рекомендаций разработчиков, бэкапирование базы данных делается через функцию экспорта (известно, что некоторые делают так), то после восстановления базы импортом, ссылки по GUID перестанут быть актуальны. А ссылки по 903-му полю останутся действующими. Но отмечу особо: случай бэкапирования через экспорт демонстрирует не преимущество ссылок через 903-е поле, а последствия неправильного бэкапирования.



Редактировано 1 раз. Последний раз 27.05.2020 15:24 пользователем SokV.

А как правильно бекапировать?

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

Хотя бы потому, что при переходе на новую версию ИРБИС безусловно нужно осуществлять экспорт/импорт... Так, к слову, рекомендуется поступать в инструкции от разработчиков. См. Приложение.

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

Может всеж-таки стоит GUID поместить в поле с меткой 1 в новых версиях ИРБИС и несколько пересмотреть технологии идентификации записей с учетом всех потребностей ее использования?

Где (в каких технологиях) сейчас задействован GUID в ИРБИС?
Ни на форуме ни в документации информации о GUID нет...

Возможно, я выразился слишком категорично насчет "правильного/неправильного". Нельзя дать универсальный способ, как правильно бэкапировать. Это тема со множеством аспектов, во многом выходящая за рамки системы ИРБИС. Основные вопросы, на которые должен ответить для себя администратор, настраивающий резервное копирование: резервные копии каких именно данных нужно создавать; каким инструментом; как часто; где и сколько времени хранить копии; неплохо задуматься о контроле валидности создаваемых и хранимых резервных копий.

Что касается рекомендаций от разработчиков, есть специально предназначенный для бэкапирования инструмент в АРМ Администратор. Создание резервной копии осуществляется с помощью пункта главного меню Сервис – Копировать файл документов.

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

Очень полезным, а иногда и спасительным могут быть копии папок ИРБИС (особенно, если вы вносите изменения в файлы окружения или собираетесь делать обновления).

Если администратор понимает, что и по какой причине он делает, то и экспорт может быть вполне подходящим способом резервного копирования.



Редактировано 1 раз. Последний раз 27.05.2020 15:23 пользователем SokV.

А. Роман написал(а):
-------------------------------------------------------
> Владимир, ну вот при всем личном уважении в том,
> что экспорт - это не правильный способ
> бэкапирования никак не могу согласиться!
>
> Хотя бы потому, что при переходе на новую версию
> ИРБИС безусловно нужно осуществлять
> экспорт/импорт... Так, к слову, рекомендуется
> поступать в инструкции от разработчиков. См.
> Приложение.
>
> При этом как понимаю со ссылками сформированными
> где-либо с использованием GUID можно будет
> попрощаться, т.к. GUID у импортированных записей
> будет с новым значением?
>
> Может всеж-таки стоит GUID поместить в поле с
> меткой 1 в новых версиях ИРБИС и несколько
> пересмотреть технологии идентификации записей с
> учетом всех потребностей ее использования?
>
> Где (в каких технологиях) сейчас задействован GUID
> в ИРБИС?
> Ни на форуме ни в документации информации о GUID
> нет...


Совершенно верное замечание, при переходе на новую версию через экспорт/импорт ссылка через GUID перестанет работать. Это недостаток использования GUID для постоянной ссылки.

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

Знаю, что размещение GUID в полях отвергли, чтобы не было возможности его правки.



Редактировано 1 раз. Последний раз 27.05.2020 15:21 пользователем SokV.

А. Роман написал(а):
-------------------------------------------------------
> Владимир, ну вот при всем личном уважении в том,
> что экспорт - это не правильный способ
> бэкапирования никак не могу согласиться!
>
> Хотя бы потому, что при переходе на новую версию
> ИРБИС безусловно нужно осуществлять
> экспорт/импорт... Так, к слову, рекомендуется
> поступать в инструкции от разработчиков. См.
> Приложение.
>
> При этом как понимаю со ссылками сформированными
> где-либо с использованием GUID можно будет
> попрощаться, т.к. GUID у импортированных записей
> будет с новым значением?

Верное замечание. Подумаем над режимом СПЕЦИАЛЬНОГО экспорта с сохранением GUID...

Спасибо!

Konstantinus написал(а):
-------------------------------------------------------
> А в чем преимущество по сравнению с 903-м полем?

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

При переходе на новую версию с импортом-экспортом все GUID конечно сбросятся. Но в новой инструкции требование переноса через текстовые файлы относится только к «обновлению» с версий младше 2018.
Как я понимаю, сейчас достаточно просто скопировать файлы документов

*.IFP; *.L01; *.MST; *.N01; *.XRF

Формат базы не меняется. По крайней мере при переходе с 2018 на 2019.
А при обновлении через git и копировать ничего не надо, параметрические файлы заменятся, а файлы документов останутся как есть.

Раньше при обновлениях зачем-то предлагали менять вообще всю ссылку, так как номер версии включался в сам URL. /irbis64r_15/ В новом веб-ирбисе уже постоянное имя /irbis64r_plus/

--
Сергей Кузнецов

> Раньше при обновлениях зачем-то предлагали менять
> вообще всю ссылку, так как номер версии включался
> в сам URL. /irbis64r_15/ В новом веб-ирбисе уже
> постоянное имя /irbis64r_plus/


Это параметрируется (и раньше было так же) ini-файлом установщика Веб-ИРБИС.

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

Попробовала сделать ссылки через GUID. Правда при изменении файла \Deposit\fullwebr.pft ничего не увидела, поэтому сделала через файл BriefHTML_ft.pft.
Я добавила еще чтобы ссылка заходила под гостем.

'<A title="Постоянная гиперссылка" style="cursor: pointer; font-size : 11px;" HREF="',
&uf('IWEB,CGI_ALIAS,'),
'?I21DBN=',&uf('Av2221#1'),
'&P21DBN=',&uf('Av3331#1'),
'&C21COM=S',
'&S21FMT=briefHTML_ft',
'&Z21ID=GUEST',
'&S21P03=GUID=',
'&S21STR='&uf('+*'),
'">--</a>',

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

SokV написал(а):
-------------------------------------------------------
> Кстати говоря, это было неплохо: по умолчанию
> поставить новую версию рядом, а не взамен старой.

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

Мы пока не решились переходить на Web Ирбис+, мой пример с постоянной ссылкой относился к старому интерфейсу.

--
Сергей Кузнецов

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

> При этом как понимаю со ссылками сформированными
> где-либо с использованием GUID можно будет
> попрощаться, т.к. GUID у импортированных записей
> будет с новым значением?
>
Выход есть - бэкапиться собственной утилитой.
При записи в БД GUID естественно остаётся прежним, таким образом я могу реализовать постоянную связку записей по GUID. Естественно, что если кто-то без меня сделает экспорт-опустошение-импорт через "Администратор", то всё поломается.

Однако, GUID записи в исполнении ИРБИСа - это велосипед на костылях :)
Само заявление о том, что импорт записи с GUID может привести к дублированию GUID в базе - смешно. Если в базу вводится запись с дублирующим гуидом, то ядро БД выдаёт ошибку или исключение, и оператору/программе понятно, что фокус не пройдёт, и надо что-то предпринять - например, сформировать для записи новый гуид (так во "взрослых" СУБД). Но, ИРБИС же не СУБД :)

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

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

Однако, в любых базах, и во "взрослых" базах тоже, механизмы, касающиеся создания ключей, и связывания по ним записей, предназначены для того, чтобы работать в рамках базы данных. Одной базы данных.

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

Озвученное вами решение, если я правильно вас понял, загружать GUID, а в случае дублирования, создавать новый GUID, довольно странное. Это может быть правильным в одних случаях, и неправильным в других. Например, в MSSQL, если есть поле с ключём IDENTITY, то при вставке записей, нельзя давать свои значения для этого поля. Вместо этого будут присваиваться автоматически гернерируемые уникальные значения. Есть исключение из этого правила, можно включить специальный режим на время вставки, при этом будут разрешены вставки записей со своими явно указанными значениями в то самое поле типа IDENTITY. Никакого автоматического "или так или сяк" на уровне базы данных. И я вообще не уверен, что в любых современных базах, как в MSSQL, есть возможность вставки своих значений в поле, определенное как первичный ключ. Везде вопросы переноса данных, конечно же, решаются, так, или иначе, учитывая определенные нюансы.

Тривиальным вопрос переносов становится, если нужно сделать полную копию, клон базы данных, в которой в этот момент никто не работает. Это легко сделать в ИРБИС.

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

В АРМе Администратор 2019.1 исправлена ошибка, в результате которой при выполнении режима РЕОРГАНИЗАЦИЯ ФАЙЛА ДОКУМЕНТОВ С ИСКЛЮЧЕНИЕМ УДАЛЕННЫХ ДОКУМЕНТОВ GUID пересоздавались (т.е. не сохранялись прежние значения)

Также внесены изменения, которые обеспечивают СОХРАНЕНИЕ GUID при переводе БД с одной версии системы на другую (а также в случае использования ЭКСПОРТА для создания архивных копий БД), а именно:
GUID сохраняются при ЭКСПОРТЕ при выполнении следующих условий:
- ИСХОДНЫЕ ДОКУМЕНТЫ - ВСЕ
- ТВП ПЕРЕФОРМАТИРОВАНИЯ - не используется
- ВЫХОДНОЙ ФОРМАТ - ТЕКСТОВЫЙ

Исправленный вариант появится в D4



Редактировано 1 раз. Последний раз 30.06.2020 14:49 пользователем Alio.

Оно конечно хорошо, но система не обеспечивает уникальности GUID записи в базе.

Возможны разные варианты действий, но результат один - вполне вероятно появление в базе нескольких записей с одинаковым GUID.

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

Получили дистрибутив 2019.1 с D4, АРМ "Администратор" делает выгрузку базы без GUID

SokV написал(а):
Посмотрите в сторону MongoDB, она к ИРБИСу гораздо ближе, чем MSSQL
Поле GUID очень хорошо подходит для связывания записей, гораздо больше, чем связывание по "шифру документа", который в ряде случаев также может меняться, в том числе при экспорте-импорте.
Об этом тут уже писали.


-------------------------------------------------------
> В современных (и даже не очень) реляционных базах
> данных для полей таблиц, где это необходимо, можно
> создать соответствующие этим полям объекты,
> которые могут обеспечивать уникальность значений
> поля для всего набора записей, запрещая добавлять
> неуникальные значения. Или же не только следить, а
> генерировать новые уникальные значения, при
> добавлении новых записей, например, в виде целых
> чисел (последовательно или в случайном порядке),
> или же гуид. Эти специальные объекты в разных
> базах реализуются и называются по разному: индекс,
> последовательность, специальный тип данных поля в
> таблице.
>
> В ИРБИС сейчас нет специального механизма, защиты,
> обеспечивающей невозможность вставить неуникальные
> значения в каком то поле в разных записях. В этом
> разница. С этим и связаны опасения получить
> неуникальные значения GUID.
>
> Однако, в любых базах, и во "взрослых" базах тоже,
> механизмы, касающиеся создания ключей, и
> связывания по ним записей, предназначены для того,
> чтобы работать в рамках базы данных. Одной базы
> данных.
>
> Вопросы выгрузки записей вместе с их ключами,
> идентификаторами из базы, и загрузки данных извне,
> всегда сопровождаются всякими нетривиальными
> моментами, особенно если перенос осуществляется
> порциями, и тем более, если данные правятся между
> выгрузками-загрузками. Это естественно, и это не
> техническая проблема уровня программного
> обеспечения. Это вопрос модели данных и сохранения
> целостности данных при переносах.
>
> Озвученное вами решение, если я правильно вас
> понял, загружать GUID, а в случае дублирования,
> создавать новый GUID, довольно странное. Это может
> быть правильным в одних случаях, и неправильным в
> других. Например, в MSSQL, если есть поле с ключём
> IDENTITY, то при вставке записей, нельзя давать
> свои значения для этого поля. Вместо этого будут
> присваиваться автоматически гернерируемые
> уникальные значения. Есть исключение из этого
> правила, можно включить специальный режим на время
> вставки, при этом будут разрешены вставки записей
> со своими явно указанными значениями в то самое
> поле типа IDENTITY. Никакого автоматического "или
> так или сяк" на уровне базы данных. И я вообще не
> уверен, что в любых современных базах, как в
> MSSQL, есть возможность вставки своих значений в
> поле, определенное как первичный ключ. Везде
> вопросы переноса данных, конечно же, решаются,
> так, или иначе, учитывая определенные нюансы.
>
> Тривиальным вопрос переносов становится, если
> нужно сделать полную копию, клон базы данных, в
> которой в этот момент никто не работает. Это легко
> сделать в ИРБИС.
>

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

> Насчёт велосипеда - GUID внутренний механизм, не
> был сделан для вас. Зачем вы сели на этот
> велосипед? :-) В любом случае, интерес играет
> большую роль, благодаря этому интересу от
> пользователей, как выше было написано, механизм
> будет совершенствоваться.