Конфликт блокировок при выполнении транзакции #578278

8.2.13.219 Зарплата и кадры бюджетного учреждения, редакция 1.0.28.1 Режим серверный MS SQL 2008 R2 При активной работе пользователей с базой, а конкретно при расчете с нескольких машин одновременно документа(не одного а разных) "Начисление зарплаты", получаю: Конфликт блокировок при выполнении транзакции: Microsoft OLE Provider for SQL Server: Транзакция(идентификатор процесса 62) вызвала взаимоблокировку ресурсов блокировка | буфер связи с другим процессом и стала жертвой взоимоблокировки. Запустите транзакцию повторно. HRESULT=80004005,SQLSrvr:SQLSTATE=4001, state=50, Severity=D, native=1205,line=1 Полагаю, что дело в обращении к регистру расчета "ОсновныеНачисленияРаботниковОрганизаций", а точнее к его виртуальной таблице "ФактическийПериодДействия". Что делать и нормально ли это вообще?

ап

это даннасть, любые регламентные операции так себя ведут

одновременные документы по одному подразделению (сотрудникам) ?

>> ...нормально ли это вообще? Да. >> Что делать ...? Не проводить одновременно документы расчета. Ну или хотя бы не проводить одновременно расчет по одним и тем же сотрудникам.

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

>> Может им график раздать когда можно? Ну... как вариант - можно и график составить. :) >> Не обязательно. Уточняй. По идее взаимоблокировки будут при одновременном расчете по пересекающимся наборам измерений (ФизЛицо, Подразделение, Организация).

Таким образом 1С не рассчитана на работу двух и более сеансов одновременно в части подобных расчетов? Чувствую, что это не так. Может есть какой-нибудь извращенный способ решения? Например переписать расчет. Использовать другой SQL(у меня версия без апдейтов). Как-то запретить пользователям рассчитывать и проводить начисления, если подобные действия проводятся в другом сеансе. Неужели все смирились с этим?

Сеансов может быть сколько угодно. Но проводить одновременно расчеты по одному и тому же сотруднику невозможно. Чудес не бывает. Этого тебе не позволит ни одна учетная система. 1С тут не при чем. Надо разбираться в причинах взаимоблокировок в твоём конкретном случае.

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

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

знаю компанию где расчеты запускаются только ночю регламентным заданием расчет идет примерно 6 часов :) в рабочее время сотрудники имеют право перерасчитывать только по одному сотруднику

Согласен, думал может не знаю чего хитрого в механизме блокировок или проблема в СУБД. А оно вот как. Убедительно. Я так понимаю: в этой ситуации надо запретить одновременные расчеты по совпадающим измерениям регистра ОсновныеНачисленияРаботниковОрганизаций. Либо флагом, либо блокировкой, либо добрым словом.

скорее всего какие-то умельцы полазили там у вас в модулях. Конфа типовая?

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

Конфа не типовая. Документ типовой.

Сейчас как раз накатываю на тестовую базу типовую. Тоже были подозрения.

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

Запустил на одной машине 3 сеанса и рассчитываю разные документы одновременно, получил: Конфликт блокировок при выполнении транзакции: Microsoft OLE DB Provider for SQL Server: Превышено время ожидания запроса на блокировку. HRESULT=80040E31, SQLSrvr: SQLSTATE=HYT00, state=33, Severity=10, native=1222, line=1 Я так понимаю, что это уже настройки самого SQL, в части тайм аута попытки блокировки. Так?

Совершенно тоже поведение типовой. Только что проверил. Значит дело не в кривых руках.