Запрет На Дублирования Документов С Readers Полями

[savl]

Задачку поставили:
Необходимо предотвратить создание дубликатов документов по ряду параметров.
Суть: не дать сохранить документ если по неким параметрам такой же уже найден в базе.
Особенность: есть Readers поля и пользователь создающий новый документ может не видеть уже созданные.
Собственно как быть? Есть идеи?

 

[Kizarek86]

Запускать агент на сервере под именем пользователя имеющего доступ ко всем документам

 

[savl]

на QSave по не сохраненному документу?
как обработать результат агента?

 

[Medevic]

Дать сохранять, но не ставить правильный статус и делать видимым только автору. Сервер периодически проверяет на дубли. Если не найдены, то ставим статус и делаем видимым. Иначе заворачиваем документ.

 

[Мыш]

Или хранить данные, по которым дублирование недопустимо, отдельно, "в общем доступе". НО это изврат...

 

[lmike]

на QSave по не сохраненному документу?
как обработать результат агента?

через сервисный док, кот. как параметр к агенту на сервере

 

[savl]

lmike, думал об этом.

Пока есть так:
Категоризированная вьюха, галка don't show empty category снята.
Очень жесткий отбор документов

Dim vals As Variant
vals = view.GetColumnValues(0)
If Not Isnull(Arraygetindex(vals,key)) Then
Messagebox "Счет с таким номером уже существует", 16, "Ошибка"
Continue = False
Exit Sub
End If

Минусы подхода по мимо переполнения массива какие еще могут быть?

 

[Мыш]

Минусы подхода по мимо переполнения массива какие еще могут быть?

Минус тут такой - вы "светите" данные из документов, к которым доступ ограничен...
UPD. Я к тому, что если есть вид, доступный юзеру, и содержащий ЧАСТЬ данных из документа (в категориях), то это уже не совсем секьюрненько

 

[savl]

Так таковых данных нет, только сообщение

 

[Medevic]

Минусы подхода по мимо переполнения массива какие еще могут быть?

Теоретически можно создать дубль при почти одновременном сохранении.
Работать будет только в одной реплике.

 

[Мыш]

Работать будет только в одной реплике.

С неск. репликами вообще сложно - тот же единый счетчик, скажем...
"Мгновенный ответ" все же лучше, т.к. пользователь может сохранить "заявку на документ" и благополучно забыть про нее. А потом - когда сервер ее откажет - будет шуметь: "Что за фигня, я же все СОХРАНЯЛ!!!".

 

[savl]

да, в пределах реплики это факт, агент на сервере тоже в пределах реплики...
может кто Api какое знает?

Или хранить данные, по которым дублирование недопустимо, отдельно, "в общем доступе". НО это изврат..

Да не такой уж и изврат, создать базу индексирования и проверять там наличие документа.
По идее быстрая проверка, с другой стороны лишняя база и лишние обращения.

 

[Мыш]

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

 

[savl]

Мыш
Ну по факту да, это оно и есть.
Только вот вопрос скорости разных реплик все равно открыт, общего сервера нет.
Реплики у меня всегда узкое место будут.

 

[Мыш]

savl, нууу, с неск. репликами засада. Теоретиццки - иметь один экземпляр базы с хэшами на некоем "главном" сервере и работать напрямую с ней из всех локаций (скажем, через RunOnServer-агент). Но это, сами понимаете, жесть некоторая.. -_-

 

[Medevic]

С неск. репликами вообще сложно - тот же единый счетчик, скажем...
"Мгновенный ответ" все же лучше, т.к. пользователь может сохранить "заявку на документ" и благополучно забыть про нее. А потом - когда сервер ее откажет - будет шуметь: "Что за фигня, я же все СОХРАНЯЛ!!!".

Да не так сложно. Просто такими вопросами должен рулить один сервер. Или в зависимости от параметров документа определяться "рулевой" сервер.

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

 

[savl]

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

 

[Мыш]

savl, теоретиццки это может быть ЛЮБОЙ (даже не лотусовый) сервис, надежно доступный из обеих локаций и обеспечивающий уникальность хранящихся данных. Навскидку - пробовать писать по FTP файл с именем, соответствующим хэшу (затраты на трафик копеечные). Если файл есть - ругацца. Ну и т. п.

 

[savl]

Мыш
Это тема, но точно изврат -_-

 

[lmike]

не файл писать, а вебсервис для хэшей