Недавно обновили релиз УПП сразу с 1.2.32 на 1.3.20 (конфа доработанная) Стали часто выскакивать сообщения о конфликте блокировок. (sql server 2005), более 60 одновременно работающих пользователей. Причем сообщения выскакивают, если документ проводится неоперативно. Посмотрела в свойствах конфы, раньше стояло автоматическое управление блокировками, теперь управляемые блокировки. Подскажите пож-та, что делать в такой ситуации, может стоит в скле настройки какие-то сделать? Прочитала, что можно из скл сделать версионник. Кто пробовал. Или все-таки надо поставить авто в настройках управления блокировками?

Дописки свои перевести на управляемые блокировки

УПП 1.3 на управляемые перевели чтоли? чтот пропустил этот момент

(1) у тех документов, которые блокируют, нет дописок

+(3) точнее совсем нет дописок, связанных с проведением документов, именно в части движений и обращений к регистрам, создана только подписка на событие при проведении документов, где проверяется, доступна пользователю роль (проведение задним числом) или нет, и если нет, то отказ в проведении. Все остальные изменения - это реквизиты и изменения в формах.
(2) получается так, сама ничего там не меняла

"если документ проводится неоперативно"
"где проверяется, доступна пользователю роль (проведение задним числом) или нет"

подозрительная случайность прям.

Как проверяете?

В процедуре модуля для подписки:    
Если не РольДоступна("РазрешитьНеоперативноеПроведение") и  День(Источник.Дата)<> День(ТекущаяДата()) и не Источник.Проведен и не Источник.ПометкаУдаления и не РежимЗаписи=РежимЗаписиДокумента.Запись и Тогда
           #Если Клиент Тогда
           Предупреждение("Проведение документа ""задним числом"" запрещено!");
           #КонецЕсли
           Отказ = Истина;
       КонецЕсли;    

До обновления все работало и никаких проблем не было.

ага, на новом релизе УПП в модулях документов появились вставки в стиле..., дожили наконец

       СтруктураПараметровБлокировка = Новый Структура("ТипТаблицы, ИмяТаблицы", "Справочник", "ОбособленныеПодразделенияОрганизаций");
       
       ЗначенияБлокировки = Новый Структура;
       ЗначенияБлокировки.Вставить("Ссылка",      Касса.ОбособленноеПодразделение);
       ОбщегоНазначения.УстановитьУправляемуюБлокировку(СтруктураПараметровБлокировка, ЗначенияБлокировки, , Ложь, "");

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

(6)Предупреждение в транзакции это зачет! :)

(6)О_о

(9) да, есть косяк, надо переделывать. Кстати, если сделать сообщение, транзакция завершается? или есть другой механизм сообщений пользователей, но при этом завершение транзакции?

Может все-таки стоит покрутить СКЛ?

скорее срабатываю "новые" блокировки из модулей объектов, а ваш подписчик не при чем, но это спорно

(6) клева... и пусть весь мир подождет...

(12) вот и я думаю, потому что до этого все работало на ура - никто не блокировал.

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

(11)Попробуй через Сообщить.

Начинается транзакция. Открывается окошко Предупреждение И чел тупо в него в тыкает.
А остальные люди не могут использовать регистры по заблокированным измерениям.

Кстати подписка на какое событие?

(11)>>или есть другой механизм сообщений пользователей, но при этом завершение транзакции?


Сообщить("!");
Отказ=Истина;
Возврат;

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

>Может все-таки стоит покрутить СКЛ?

скуль при управляемых блокировках бывает уже не причем...

(11)(15)И не "попробуй", а бегом переделывать хотя бы на Сообщить(), пока никто не видел. :)

(18)Выбрось это из головы. Если случайно проведут - отменят

(16) ПередЗаписью

Тогда не должно влиять.

(21) не отменят - отмена задним числом тоже запрещена, точнее вообще запрещена. Иначе не отловить концов по учету.

(18)все вопросы пользователю надо задавать до начала транзакции, иначе он может в процессе принятия решения и покурить выйти, а данные будут заблокированы!

(24)Значит пусть следят за руками.А если случилось страшное, топусть идут к тебе и ты отменишь.Надеюсь себя ты такой привелегии не лишила?

(18) Для этого есть событие ПередЗаписью. Там проверять режим записи документа, даты и т.п.

(19) http://comol.livejournal.com/558.html - вот здесь как раз пишут, что срабатывает только при управляемых.

+(26)Но если сильно хочется подстраховаться, спряч "ОК" в подменю.Тогда точно случайно не не нажмут

(28) там вообще про другое речь... втыкайте лучше в тексты

(26) >> Надеюсь себя ты такой привелегии не лишила?

Какого х... разработчик вообще делает в рабочей базе?... Он за данные ответственности не несет.

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

(32) Кто вам запретил делать подписки на событие ПередЗаписью? О_о

(31)Может и не несет.Но лучше такие моменты держать под контролем.

(32)Тогда как вариант попробуй (29)
А предупреждения и вопросы...Подавляющее большинство будет жать "Да" даже не задумываясь:-)...Так что вряд ли поможет

(29) низззя)))
(30) про что, про другое? разве это к теме не относится?
(31) я тоже так считаю, но работодатель думает по-другому(((
(33) перед записью и сделана подписка

(36) все "зя" если захотеть:-)

Да, кстати, может платформу стоит обновить до 8.2.15, сейчас 14.540 стоит? Или там тоже в эту сторону ничего не улучшено?

Просто перерыла кучу информации и нигде ничего толком не написано((((
Где-то было написано:  "В новом домене не было политик, связанных с параметрами производительности серверов
(power options, performance - visual effects). И к серверам применились настройки по умолчанию."

Но это же вообще связано с изображением, как это может влиять.

Событие ПередЗаписью возникает уже после начала транзакции, в нем уже нельзя использовать диалоги с пользователем.

(35) прав, чаще всего так и происходит пользователи не думают о том, что там зе ересь вылезла - тупо жмут "да"
и толку с этого вопроса.

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

но такая реализация сложновата

А вообще зачётная проверка  День(Источник.Дата)<> День(ТекущаяДата())  :)))
Т.е. 13-го числа текущего месяца я смогу провести документ от 13-го числа предыдущих месяцев :)))

>> Подскажите пож-та, что делать в такой ситуации
разбираться дальше из-за чего блокировки. режим УБ здесь не причем.

найди в каком месте возникает ожидание блокировки и копай.

Просто уровень пользователей таков, что кнопкой ОК они пользуются для закрытия документа, не делая различий, между записать, закрыть и просто провести и уже не заставитьих думать по-другому((((((

(43) Как? Читала про ЦУП, но он платный и пока мне никто не даст его приобрести, а проблему надо решать в ближайшее время.

(44)Тогда перенеси кнопку ОК вверх куданибудь подальше от Закрыть

(45) тех. журнал настрой хотя бы...

или напиши на ней большими буквами "ПРОВЕСТИ!!!!" :-)

+(45) знаю одно решение проблемы, но лично для себя - заявление на увольнение)))))))))))))
шутки шутками, но мозг сломан

Неужели у всех УПП при больших объемах данных и с большим количеством одновременно работающих пользователей  работает без проблем.

Кстати, добавлены новые роли, но без ограничений. Они могут влиять?

Прочитала, что еще железо сервера может быть виновато, но на что там посмотреть не знаю, так как не разбираюсь в этом совсем.

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

(51) это же волшебный форум )

(51) В рот мне ноги!! :)))

(51) Тока давайте без этих наставленческо - уменьшительно-ласкательных обращений, ок?
Я обращаюсь за советом к людям, которые уже сталкивались с подобным, либо к тем, что что-то знает по этой проблеме. Как и все форумы, этот создан я так понимаю для этого;))

(54) могу сказать с уверенностью на 80% что типовой код проведения не приводит к дедлокам.

(43)а что тут думать, на этих предупреждениях и вопросах и блокируется все. Ну т.е. на них точно блокируется - это 100%. Это первое что надо убрать.

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

Ответь на (42)

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

(55)а причем тут дедлоки? В (0) сказано просто о "конфликте блокировок", это не дедлоки вовсе.

(57) Вроде для партионного учета УБ в типой не сделаны.
Т.е. вполне может быть ситуация когда изменяются прочитанные данные без установленной блокировки.

(42) кстати даже не обращала внимания, до меня написано было, надо проверить, спасибо))))))

(61) и что в таком случае делать? дописывать или изменить на авто?

без понимания лучше не делать нифига...

(59)а использование Вопрос(), описанное в (18)?

(65) еще пока не используется

Такая же проблема коснулась второй базы, которая вовсе не дописана. Везде стоит партионный учета и списывать партии при проведении документов. Ругается как раз на модуль проведения по партиям при неоперативном проведении документов.  Менять на РАУЗ или проводить по партиям обработкой не предлагать - не подходит ни то, ни то.

Я так понимаю, перевели УПП на управляемые блокировки, но не доделали партионный учет?

(67) Все доделали. Партионный учет не способен работать лучше. Решения есть - проводить по партиям отдельно, либо РАУЗ. Вам не подходит. Ну раз не подходит - кушайте кактус.

(68) партионный учет работал отлично, пока не стали управляемые блокировки. При этом на самом SQL выполнялись рекомендуемые операции раз в неделю и никаких проблем с блокировками не возникало. РАУЗ не подходит хотя бы потому, что он не поддерживает обособленный учет товаров, некоторые отчеты нельзя посмотреть в реальном времени(например, продажи по оплате). А если не списывать партии при проведении документов, то и стоимость не будет видна в момент проведения. А у нас бухгалтерия требует, чтобы при печати тех же требований-накладных была заполнена стоимость. Ждать вечера, чтобы распечатать, а потом бегать за людьми, чтобы расписались как-то не очень.  
В данном случае Ваше выражение "кушайте кактус" как-то мягко говоря неуместно.
Пользователи хотят работать как и раньше, а так получается программа диктует условия, хотя насколько я помню "гибкость" - одно из заявленных свойств.

(69) Партионный учет работал отлично пока в середину блокировки предупреждение не воткнули. Для этого вообще-то есть "ОбщегоНазначения.СообщитьОбОшибке()".

c какого релиза  УПП на управляемые блокировки начали переводить?

(70) воткнули давно и работало с предупреждением (сейчас все заменено на сообщить), но при этом блокировки остались. Причем выше я написала, что на полностью типовой тоже самое. В таком ключе как пишите Вы, лучше не писать, меня интересуют конструктивные предложения и замечания.

(71)в 1.3.20 они уже точно есть;)))