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

@anna,

попробуйте построить представление с категоризацией по всем читательским полям (галку Don't show empty categories НЕ ставьте). по-идее, могут быть пустые подозрительные категории, где и будут фантомные доки.
 
Поддерживаю oshmianski.
2 одинаковых UNID документа быть не может в одной базе.
Иначе рушится вся парадигма NSF. Смотрите - у вас явно где то косяк.
 
Поддерживаю oshmianski.
2 одинаковых UNID документа быть не может в одной базе.
Иначе рушится вся парадигма NSF. Смотрите - у вас явно где то косяк.
Я и не спорю, в БД не может быть два документа с одним Unid. Однако, RTFM - мы запросто можем создать второй документ и он заменит первый. У этого второго дата создания будет как у первого, а дата модификации - дата внутренней репликации (репликация внутри одной базы), она же - дата создания второго дока.
Косяк есть, но он в другом - документ недоступен и я не могу его вынуть ничем. У меня есть еще 2 таких таинственных юнида, с которыми можно производить опыты.
 
Последнее редактирование модератором:
Во вью типа Trash он не отображается случайно?)

Какие св-ва у документа после db.GetDocumentByUNID(unid) ?
isArray(doc.items)\isDeleted\isValid\doc.UniversalID ?

PS. Вообще - UNID это ф-ция от текущей даты (создания дока упрощенно;))
 
shit happens- только что пришел еще один такой же инцидент. Но на сей раз пользователь сообщил, что при сохранении документа выдавало "Ошибка Notes. Неверный или несуществующий документ". Может, это таки ECL? как заставить принять ECL при отказе формирования ключей?
 
>Во вью типа Trash он не отображается случайно?)
Нет
>Какие св-ва у документа после db.GetDocumentByUNID(unid) ?
Докумен по юниду не берется, он Nothing
>isArray(doc.items)\isDeleted\isValid\doc.UniversalID ?
см выше
>PS. Вообще - UNID это ф-ция от текущей даты (создания дока упрощенно;))
я в курсе. однако, RTFM
 
Тогда не понятно - а почему вообще решили что этот док есть в базе?
 
@anna: удалите всё из БД кроме странного для вас, снесите весь дизайн, снимите локальное шифрование и покажите нам.
 
Тогда не понятно - а почему вообще решили что этот док есть в базе?
Потому что: 1) уведомление рецензенту таки приходит со ссылкой - а уведомление рассылается только после сохранения документа
2) вышеприведенный эксперимент показывает, что все-таки документ с таким юнидом был создан и повторное использование этого юнида приводит к созданию документа с датой создания на 4 дня раньше текущего времени.
 
@anna: удалите всё из БД кроме странного для вас, снесите весь дизайн, снимите локальное шифрование и покажите нам.
О, а мне нравится эта идея! я сделаю копию и удалю все-все валидные документы, снесу дизайн и посмотрю, что осталось. Зачот!
 
1) уведомление рецензенту таки приходит со ссылкой
Сорри - это т.н. вторичные половые признаки:) Ссылка может быть, а документа может и не быть.
Как вариант - этого дока не должно быть в этой базе согласно формуле реликацц\асл.
вышеприведенный эксперимент показывает, что все-таки документ с таким юнидом был создан
Повторно юнид можно использовать сколь угодно ко-во раз с одним только условием - в базе не должно существовать *валидного* документа с аналогичным UNID.
 
100% не сохранение документа. Если железно знать что документ сохранен, с UNID-оми никаких заморочек не должно быть.
Обратите внимание на глобальность переменной по сохраняемому NotesDocument, проверте поле SaveOptions, явное перебивание UNID документа и т.п. Сделайте копию в конце концов со значениями из текущего документа в новую форму, чтобы явно убедиться что не происходит сохранение.
 
Сорри - это т.н. вторичные половые признаки:) Ссылка может быть, а документа может и не быть.
Как вариант - этого дока не должно быть в этой базе согласно формуле реликацц\асл.

Повторно юнид можно использовать сколь угодно ко-во раз с одним только условием - в базе не должно существовать *валидного* документа с аналогичным UNID.
Я сохраняю док, и только потом рассылаю. SaveOptions - надо подумать
Так я и не говорю, что он был валидный. Но был, раз уж дата создания дока об этом говорит.
 
Разогнался я консультировать )) у самого такая беда есть в базе по наследству, но только на момент сохранения и в той базе где служебки тоже. Короче да, вылазит от одних и тех же пользователей 4412 -> Notes Error - Invalid or nonexistent document при попытке сохранения... у меня затычка поставлена на эту ошибку и делается копия документа дальше уже все ок. Вылазить стало в связи с переходом на 9-ки. Много раз пытался узнать причину, встречал подобное описание проблем, но решение в виде копии кажется только и нашел. По-моему, ошибка получается иногда у пользователей, которые создают документ, который имеет уже вложение, редактируют его, а затем пытаются все сохранить. Вот я им раньше рекомендовал, всегда сохранить сначала документ, а уж затем делать изменения во вложении.
 
ак я и не говорю, что он был валидный. Но был, раз уж дата создания дока об этом говорит.
дата создания в данном случае говорит ни о чем)
Юзаю конструкцию иногда doc.id=db.createdocument.universallID. этот id в этом контексте то же не говорит о времени)
у меня затычка поставлена на эту ошибку и делается копия документа дальше уже все ок.
Ну т.е. все равно док не сохраняется. Нету его.
Ну, мы тут недавно ловили уже призрака. Получалось :)
Это призрак как то должен браться через апи\лс. Если не берется - то нету призрака)

А чего я упорствую?

Пока использую такую конструкцию, который в итоге говорит что дока нет для прикладной системы и UNID можно заюзать.
Код:
Property Get GetDocumentByUID(db As NotesDatabase, UID As variant) As NotesDocument
        On Error Resume Next
        Set GetDocumentByUID=db.GetDocumentByUnid(uid)
        On Error GoTo 0
        If GetDocumentByUID Is Nothing Then
            Set GetDocumentByUID = Nothing
        Else
            If Not GetDocumentByUID.isValid Or GetDocumentByUID.UniversalID = "" Or GetDocumentByUID.IsDeleted  Then
                Set GetDocumentByUID= Nothing
            End If
        End If
    End Property
И для очередного велосипеда хочется понять, есть ль в запасе у индусов нечно необычное:)
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!