Россыпь мелких вопросов

[Shandrik]

Админ-инструментов нету

Добавлено: Спасибо!

 

[savl]

Наврал, каюсь...
только что ее раз проверил, вернул CN=, то есть основное имя...

 

[Shandrik]

Непонятно почему подвисает клиент по нажатию кнопки с кодом:
@Command([RunAgent];"myAgent");

Агент цепляет две библиотеки, в одной из которых имеется Uselsx "*javacon". Может из-за этого виснуть? Может на машине что-то не так с Явой?
В Initialize библиотек просто инициализация и проверка платформы - две строки.
Вот начало агента (следующей строкой идет Print, который не выводится):

	Set session = New NotesSession
Set db = session.CurrentDatabase
Set currSrv = New NotesName(db.Server)

Set evnt = New NotesDocument(db)
Set config = db.GetProfileDocument("Config")
evnt.ReplaceItemValue "Form","RawIN"
evnt.ReplaceItemValue "$ConflictAction","3"

Set item = evnt.ReplaceItemValue("InTime", evnt.Created)
item.IsProtected = True

evnt.ReplaceItemValue "EvntServer", currSrv.Canonical
evnt.ReplaceItemValue "$NoPurge", Cdat(evnt.InTime(0)+Cint(config.EvntLifeTime(0)))
Set item = evnt.ReplaceItemValue("UserName", session.UserName)
item.IsAuthors = True
item.IsProtected = True

 

[lmike]

поставьте вывод ошибок и агенты не выводят через Print - MsgBox

 

[Shandrik]

Да, забыл написать.
Во время зависания в статусбаре:

Opening...

 

[lmike]

Ссылка скрыта от гостей

 

[Serduko]

Подскажите, как класс может передать экземпляр самого себя?

 

[Serduko]

Вспомнил, "Me"

 

[savl]

Есть задача, проверка лимитов по оплате.
Есть некий лимит, нужно во все документы, которые уже его превышают ставить признак.
Документы ограничены по readers, следовательно сотрудники могут не видеть всех оплат и корректный подсчет лимита невозможен.
Пока есть такие варианты:
1. Считать сумму по вьюхе, в принципе сейчас так и есть, но глючит у тех, кто не видит уже созданные счета. Поэтому и надо исправлять.
2. Записывать сумму в профайл и считывать/записывать из него. Тут ограничение на одновременное редактирование профайла сотрудниками.
3. Ставить документ в промежуточное состояние, затем агентом проверять лимит и переводить на следующий статус. (системы перевода через запросы у нас нет, только планируем) Тут проблема в том, что признак появится только при переводе на следующий статус.

Пока склоняюсь к варианту 3. Может есть еще варианты?

 

[Shandrik]

А его обязательно в документ прописывать? На лету не проще высчитывать? А если лимиты поменяются?

 

[savl]

Shandrik
Лимит хранится в настройке.
На лету как? если я например из 20 документов вижу только 3 и сумма по этим трем не превышает лимит, а сумма уже по 10 превышает.
Не видя и не имея доступа к оставшимся 17 документам я не полулу корректных данных. Так уже работает, но именно из-за ограничения и есть проблемы.

 

[Domino-Designer]

Пусть сервер считает

 

[alexas1]

............
2. Записывать сумму в профайл и считывать/записывать из него. Тут ограничение на одновременное редактирование профайла сотрудниками.
...............

????
Почему обязательно открывать САМ профайл в UI.
Корректируйте сумму в бекграунде через произвольную форму для редактирования.

 

[savl]

alexas1
Никто про UI и не говорил, не придумывайте, но профайл будет не на одного пользователя, а скажем на одного поставщика.
3 человека одновременно сохраняют счет на поставщика, все трое лезут в профайл, все трое пытаются менять, конфликт? ошибка? отказ?
Можно обойти через цикл, который будет пытаться сохранить этот профайл, и если не получилось выдавать "О-па, а попробуй еще раз"
Мне нужны варианты всего лишь, как это можно сделать. Три я озвучил, хотелось бы узнать есть ли еще и чем проще - чем лучше.
Так то я пока склоняюсь к своему третьему.

 

[alexas1]

Никто про UI и не говорил, не придумывайте

Мне так подумалось, потому, что ["О-па, а попробуй еще раз" в цикле] я подразумевал по дефолту (конечно, без месседжа)
В бэкграунде конфликта не будет.
А проверка - сохранить и взять заново для контроля.

 

[Shandrik]

Shandrik
Лимит хранится в настройке.
На лету как? если я например из 20 документов вижу только 3 и сумма по этим трем не превышает лимит, а сумма уже по 10 превышает.
Не видя и не имея доступа к оставшимся 17 документам я не полулу корректных данных. Так уже работает, но именно из-за ограничения и есть проблемы.

Ага, понятно. Тогда, конечно. сервером.

 

[Darkhan]

Можно завести отдельную базу для подсчета лимитов, в которой существуют псевдо-документы различных типов лимита. В качестве счетчика можно использовать респонзы этих псевдо-документов. Т.е. при наступлении события просто респонзить один док.
При всем этом не используем поля readers

Получать псевдо-доки через Вьюху, либо по DigestSearch

Плюсы:
1) Конфликтоустойчивость
2) Быстрый подсчет итоговой суммы (.Responses.Count)
3) Слабая зависимость

 

[Shandrik]

На одном АРМе стала появляться вот такая ошибка.

При открытии базы вызывается код в библиотеке, юзающей:
Uselsx "*javacon"

Почему лотус не может его загрузить?

Java на машине стоит, в папке лотуса есть файл njavacon.dll

 

[savl]

Бывает...
Попробуйте перекомпилировать элемент с этой строкой.

Ссылка скрыта от гостей

 

[hosm]

>Попробуйте перекомпилировать элемент с этой строкой.
Вот примерно такое решение было -

Ссылка скрыта от гостей

- но проблема появлялась в процессе активной командной работы над БД. Иногда кеш втиноват, помогало просто удаление БД из воркспейса дизайнера и перезайти - если таки в либе и юзанных проблем не было или их кто-то уже починил.
по ссылке то же, что и у savl , сорри, не дочитала