Когда кто-то уже создает док, то других надо отфутболить, до того момента, пока этот кто-то не запишет док или отменит создание. Редактировать существующие можно.
Интересует решение средствами платформы, без запила своего механизма блокировок.
1С 8.2, база MsSQL.

дык блокировки только на существующие объекты можно делать

нет такого

(0) Убил бы

как вариант


сделай константу флаг - булево.
Если открыт новый - устанваливай истина и футболь осталтьных желающих проверкой ПередОткрытием на ЭтоНовый() и константа= истина

Помле записи ставь константу ложь

но все ранво это изврат

(5) За что ты так с Ранво?
http://yandex.ru/yandsearch?text=ранво&clid=1909644&lr=213&noreask=1

(4) Надо обдумать ситуацию когда при создании нового дока что-нибудь глюкнет или ребутнется комп. Т.е. док уже никто не создает, а константа указывает на обратное.

:-) Я перед ним извинюсь. Вырвалось

(7)Ну,добавить возможность ручного снятия.

Чуть подробнее о задаче:
Есть скелет документа запись в регистре сведений - это скелет документа и на его основе создается документ. Пользователи видят этот список скелетов и на их основе создают доки. Так вот нужно чтобы на основе одного и того же скелета не создали 2 дока. Я добавил флаг-поле "блок" в регистр при создании нового дока и его проверяю при создании нового и после снимаю. Проблема в том, что босс неодобряэ. Говорит, что в случае зависания клиента кто снимать такие блокировки будет?
Ну я вижу вы уже сами знаете чем это грозит :)

(9) Я бы прикрутил к механизму согласование с ответственными лицами компании, а то так любой удод будет заходить и снимать галочку.

(11)Дать права только админу и только через пиво:-)  И будет порядок

(10) У тебя толковый босс.
Он же не виноват, что ты не понимаешь, что просто тупо перед записью документа нужно смотреть, а нет ли уже такого документа.

(10)Чего ты мучаешься? При записи проверяй есть ли уже у твоего скелета подчиненные доки.Если есть - шли лесом текущего.
Кто успел - тот присел.

(1) существующий объект - таблица доков. Если можно как-то заблочить всю таблицу, то можно и так. Это идея босса и я с ней не согласен.
(13) там немного сложнее все, но скажем, что после записи дока, скелет удаляется и такого не случится, но ведь начать создание на основе одного скелета могут несколько пользователей.

(15)А что вообще за  извращение с этими скелетами? Нормальный один цельный док нельзя сделать чтоли?

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

А потом люди плюются, что 1С тупая программа с тупыми ограничениями, ага.

(17) Возьми ТС к себе на работу, на стажировку, чтобы научился)

(16) скелеты тоже особым образом создаются, здесь все упрощено, так что просто принимайте это как условие задачи.
(17) на его основе еще ничего нет, у всех пользователей начавших создание дока на основе одного скелета открыто окно документ с текстом "Новый*" в заголовке, чего быть не должно. И ,о гуру, не гневайтеся, пожалуйста ;)

(19) Ну нету и хорошо, значит можно записывать.
Уже что-то есть, значит нельзя.
Все просто.

(19) записывать сразу новый документ и проверять, как в (14), а потому уже продолжать наполнять данными

Если честно, непонятно, почему "скелетом" изначально не является новый документ?
Или наоборот, почему "скелет" изначально не является новым документом?
Нафига эти прелюдии и лишние сущности?

Вообще-то такой механизм "контроля" уже создан и используется в типовых. Когда вы заполняете "на основании" документа, то используется, зачастую, не сам документ, а его остатки.

(9) Ага, и опрашивать у 100500 коллег, никто случайно не создает в данный момент документ?

(10) нахуа, сделай зависимыми и проверяй на подчиненность. Флаги какие-то делать начинают, херня какая-то

(14) блин, сорри, недочитал ( опередил меня Пр

(22) я в (19) ответил
(21) это вариант, спасибо. Правда, есть свои тонкости, но тем не менее.
(26) а теперь до (19) дочитайте :)

две проверки - перед началом создания и перед записью

(27) ну я же извинился уже))

(28) ого, а зачем две?

(27) Просто постановка "Когда кто-то уже создает док, то других надо отфутболить, до того момента, пока этот кто-то не запишет док или отменит создание" изначально ущербная.
Но если так, то делай константой, сказали же в (4).
Какая задача, такое и решение.
Но вообще хрень полная.
Какое чье дело, что кто-то открыл форму нового документа?
Если кто-то переживает, что он не будет первым, то для него давно придумали кнопочку "Записать".

(Off) Задача, которую озвучил автор, мне напомнила проблему менеджеров сбыта, которые заполняют в диалоге различные заказы различных покупателей, заказывающие один и тот-же товар с общего склада...

(31) я разделяю ваше мнение, но задачу поставил не я. И я также не согласен с некоторыми существующим механизмами, но я работаю с тем, что есть. Попробую решить задачу через запись дока сразу после открытия.

(30) перед созданием - а вдруг уже кто создал
перед записью - вдруг кто быстрее оказался

(34) достаточно только второго

(35) думаю юзвери будут очень рады потратить какое то время, а потом получить "пшелнах"

+36 вместо того, чтобы сразу получить "пшелнах" без затраты времени

(34) не создал, а создает.

(37) хм...аргумент, согласен.

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

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

(33) А как происходит заполнение реквизиов нового документа по данным из скелетной записи? Процедуры/события какие? Обычное приложение?

Может быть в форме ПередОткрытием считывать значение дополнительного реквизита в скелете? А при закрытии формы, если записи документа не произошло - очищать этот реквизит?

Лично мне не нравится вариант записи нового документа раньше, чем юзер примет решение его сохранить сознательно.

(41) да вы , батенька, извращенец)) плодить таблицы ради такого дела, юзайте существующий функционал

(43) Криво использовать существующий функционал, не по мне. Я лучше создам все что мне нужно для получения нормального решения в т.ч. новые таблицы, если понадобится.

(40) я сейчас иду в этом направлении, спасибо.
(41) интересная мысль.
(42) запись/очистка реквизита - это примерно тоже, что и (10) с такой же проблемой. Всем скелетам суждено стать документами, за редким исключением, поэтому запись после создания вполне приемлема. Не спрашивайте, почему тогда не создаются сразу документы :)

(45) Тогда при попытке создания пользователем нового документа - искать существующую ссылку и открывать. Просто получается, что одной только ссылки будет недостаточно, чтоб сделать вывод открыта форма документа-скелета или нет. Перед открытием формы смотреть кроме поля "ссылка на документ" на поле "форма уже открыта".
В противном случае пользователи будут упорно трудиться параллельно на уже открытыми формами у соседей и ПередЗапись вслух комментироовать на устном русском системное сообщение о нарушении синхронизации с объектом

(46) Если документ создан (существует в базе), то открывается для редактирования существующий документ. Скелет после создания документа удаляется.

(44) криво использовать? не нужно утрировать, ничего кривого выше не написано

+ 48 обычные обработчики событий, что может быть проще?

(47) Тогда зачем ждать пока юзеры проснутся? Разве только в целях садо-мазо

Если садо-мазо исключить, то в начале какого-либо сеанса сгенерить все доки-скелеты... Впрочем, причин заготовки скелета можно придумать множество, а некрофильство - это только одна из них ;)

(33) А почему бы не возложить обязанность записать док на пользователя?

(51) получается, делаем удобнее программисту, а не пользователю
почти как в http://www.flibusta.net/b/106825

(52) С фига ли? Делаем так, как правильно с учетом всех факторов, а не отдельно выборочно взятых моментов.

(51) есть такие постановщики, которые прогибаются под любые хотелки пользователей ))

(54) Прогнуться-то можно, только нужно четко понимать и донести пользователю, что получается идиотское решение. Ты открываешь новый документ, а он, раз, и какого-то лешего уже записан.

(55) согласен. тем более, что по инфе от ТС, документ записан в состоянии не пригодном для дальнейшей работы с ним, т.е. нужно еще что-то совершать с данными документа и только после этого его проводить... технически можно много извратов прикручивать, только приводит это к автоматизации хаоса