• 15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby

    За 3 месяца вы пройдете путь от начальных навыков работы с SQL-запросами к базам данных до продвинутых техник. Научитесь находить уязвимости связанные с базами данных, и внедрять произвольный SQL-код в уязвимые приложения.

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

    Запись на курс до 25 апреля. Получить промодоступ ...

Массовое "replication Or Save Conflict"

  • Автор темы IsAvailable
  • Дата начала
Статус
Закрыто для дальнейших ответов.
30.05.2006
1 345
12
BIT
0
В общем, похоже, локализовал причину конфликтов:
На событии QueryOpen стоит обработка, заключающаяся в добавлении "смотрителей" в документ.
Что-то типа
Код:
Set doc = Source.Document
If  Instr(doc.GetFirstItem( "Readers" ).Text, Session.CommonUserName)=0 Or doc.GetFirstItem( "Readers" ).Text="" Then		 
Set dt = session.CreateDateTime(Now)
Set item = doc.GetFirstItem("Readers")
Call item.AppendToTextList(session.CommonUserName+Chr(9)+dt.DateOnly+" "+dt.TimeOnly)
Print "Запись в протокол доставки"
Call doc.Save(True,False)
End If
Readers - текстовое поле
Соответственно, после этого вот doc.Save(True,False) этот же документ открывается. При сохранении после изменений уже обоснованно ругается на конфликт сохранения.
И вот даже не знаю, как лучше в данной ситуации поступить... Переоткрывать документ что ли после первого открытия... Или есть способ лучше?
Просто этот doc.Save выкинуть. И так работать будет, если док-т на редактирование открывается. Вот если иногда - только на чтение.. придется мудрить
 
I

IsAvailable

Я так понимаю, придётся мудрить... :huh:
Записывать любой вход нужно.

А если на редактирование открывается, то почему нормально будет? Если пользователь ничего не изменит или выйдет без сохранений - не сохранится же запись... =\


========

Еще попробовать, может, QueryClose обрабатывать... Сейчас попробую.
Но интересно - можно ли без переоткрытия документа пользователю сразу отображать самого себя, что он зашёл...
 

puks

Lotus Team
03.02.2007
1 919
55
BIT
3
QueryClose у тебя может отрабатываться несколько раз, если пользователь получит какое-либо предупреждение и решит не закрывать документ.

Мне кажется, что может сработать следующая логика.
1) QueryOpen оставить как есть
2) В PostOpen в самое начало вставить обработку, что, если документ открыт в режиме редактирования, то сделать обновление uidoc через reload/refresh
3) И еще надо вставить подобную обработку в PostModeChange, так как документ может быть открыт в просмотре, а потом переведен в редактирование.

Можно еще с Terminate поэкспериментировать.
 
I

IsAvailable

Протоколирование Зае*енил переместил в QueryClose. В принципе, работает. Точнее сказать - наступает чарующий период тестирования ламерами пользователями. Я тестировавал под разными учетками - всё ок было, но юзеры - это юзеры...

Еще вот подумалось: может ли быть такое, что юзер зашёл, а потом вышел из документа, минуя при этом событие QueryClose? Мне представляется такой вариант: документ открывается, потом через менеджер задач глушится клиент Лотуса, потом всё открывается заново... В принципе реально... :huh:
А может, и еще какие способы есть?
 

puks

Lotus Team
03.02.2007
1 919
55
BIT
3
Это уже похоже на обсуждение security. Умный пользователь может и через свойства документа получить инфу. Или скопировать его себе в базу и там смотреть. Или ...
 
I

IsAvailable

Для: puks
Нда, вообще-то... Сегодня-завтра посмотрю на поведение базы, если останутся проблемы, то реализую ваш способ.
А пока еще про Terminate в хэлпе почитаю... Что-то я им не пользовался ни разу...
 
30.05.2006
1 345
12
BIT
0
Для: puks
Нда, вообще-то... Сегодня-завтра посмотрю на поведение базы, если останутся проблемы, то реализую ваш способ.
А пока еще про Terminate в хэлпе почитаю... Что-то я им не пользовался ни разу...
Terminate - де Дада
 
I

IsAvailable

Всё не было времени заглянуть - вот сейчас только добрался.
В общем, причина, похоже, оказалась довольно банальной и не стоившей всех тех плясок с бубнами... На серверах просто незадолго до этого было установлено ПО для сканирования документов на вирусы. В частности write scan в реальном времени. Похоже, из-за него и была вся петрушка. По крайней мере после отрубления сервисов - конфликты пропали. Вернее - бывает иногда 1-2, но массового характера нет. Такие дела.
 
Статус
Закрыто для дальнейших ответов.
Мы в соцсетях:

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