• 🔥 Бесплатный курс от Академии Кодебай: «Анализ защищенности веб-приложений»

    🛡 Научитесь находить и использовать уязвимости веб-приложений.
    🧠 Изучите SQLi, XSS, CSRF, IDOR и другие типовые атаки на практике.
    🧪 Погрузитесь в реальные лаборатории и взломайте свой первый сайт!
    🚀 Подходит новичкам — никаких сложных предварительных знаний не требуется.

    Доступ открыт прямо сейчас Записаться бесплатно

UNID есть, а документа - нет

A

anna

Коллеги, прошу мозгового штурма. Опять фигня творится. Повторяется только у одного пользователя, специально не можем воспроизвести третий месяц.
Создается в нотесе новый документ (служебка) и после заполнения отправляется на согласование, то есть, отправляется уведомление, идет сохранение. Так вот - уведомление с нормальным NotesURL есть, а документа - нет 8). То есть совсем никак нет - "Не удается найти документ, на который ссылается связь, в связанной базе данных". Окурков нет. Ничего нет.
Гипотеза про то, что документ создается в неведомой реплике - не подтверждается - идут от того же пользователя и нормальные документы. Что это?
 
Попробуйте сначала сохранить документ, потом получить его UNID.
 
  • Нравится
Реакции: savl
Без кода сложно понять, но помимо Readers еще может быть затык в ECL.
Если нет необходимых разрешений (пользователь выбрал "Не доверять"), то код не доходит до конца и не сохраняет документ.
 
Сделала такой опыт: создала в бд документ и назначила ему юнид от пропавшего документа. Без вопросов все создалось, и дата модификации этого нового документа верная, а вот время-дата Created этого дока - аккурат то самое время, которое должно быть у пропавшего дока. Это readers? И как это вылечить?
 
@anna,

теоретически, документов с одинаковым унидом быть НЕ может. время создания, вроде, является частью унида и из него вычисляется. где-то Константин Червоненко выкладывал инфу по этому поводу.
 
@anna,

теоретически, документов с одинаковым унидом быть НЕ может. время создания, вроде, является частью унида и из него вычисляется. где-то Константин Червоненко выкладывал инфу по этому поводу.
Если почитать лотус хелп, то два документа вполне может быть, просто автоматически второй становится репликой первого.
To get: unid$ = notesDocument.UniversalID
To set: notesDocument.UniversalID = unid$
мы как раз поймали этот случай - раз он реплика, то у нового документа дата создания ажно 4 дня назад. То есть док в базе был, однако он not accessible somehow
 
Скорее всего это не реплика, а конфликт репликации и сохранения.
 
Скорее всего это не реплика, а конфликт репликации и сохранения.
UniversalID property
Read-write. The universal ID, which uniquely identifies a document across all replicas of a database. In character format, the universal ID is a 32-character combination of hexadecimal digits (0-9, A-F).
The universal ID is also known as the unique ID or UNID.
Defined in
NotesDocument
Data type
String
Syntax
To get: unid$ = notesDocument.UniversalID
To set: notesDocument.UniversalID = unid$
Usage
If two documents in replica databases share the same universal ID, the documents are replicas.
If you modify the UNID of an existing document, it becomes a new document.
Saving a document with the same UNID as an existing document raises lsERR_NOTES_ERROR (4000).
See @DocumentUniqueID for another way to get the Universal ID of a document and more information.
Если бы искомый (пропавший) документ был конфликтным, то все равно возвращался бы агентом, не был бы Nothing, как мне кажется.
 
Saving a document with the same UNID as an existing document raises lsERR_NOTES_ERROR (4000).
Ключевой момент, как мне кажется. Двух одинаковых унидов быть не может. Если у вас и сохранился, то посмотрите какой унид таки реально присвоился.
 
Мы в соцсетях:

Взломай свой первый сервер и прокачай скилл — Начни игру на HackerLab

Похожие темы