Ошибка при расчёте зарплаты: Конфликт блокировок при выполнении транзакции: #739058

Здравствуйте. исходные данные: 1С 8.2 ЗКБУ база была сформирована из 1с ЗиК 7.7 конфигурация типовая пробовались разные типы баз - файловая, терминал и sql (windows server 2008. sql server 2008.) размер базы - 800Мб платформа и конфигурация обновляются регулярно. С базой работают 2 расчётчика Проблема в следующем: При одновременном расчёте заработной платы разным сотрудникам, у одного из расчётчиков(рандомно) возникает следующая ошибка: Ошибка: {ОбщийМодуль.ПроведениеРасчетовПереопределяемый.Модуль(4887)}: Ошибка при вызове метода контекста (Записать) НаборЗаписейРегистра.Записать(Истина, ТолькоЗапись, Истина, Ложь); по причине: Конфликт блокировок при выполнении транзакции: Microsoft SQL Server Native Client 10.0: Превышено время ожидания запроса на блокировку. В конфигураторе ссылается на следующую строку: Данная проблема возникает не только у нас. Фирма, которая осуществляет сопровождение сначала причиной называло медленный компьютер на котором стоит база (файловый вариант) или линии ЛВС(исключили эту причину сразу), базу перенесли на терминальный сервер - та же ошибка, на SQL то же самое. ЕСТЬ ли решение этой проблеме?

Здравствуйте. исходные данные: 1С 8.2 ЗКБУ база была сформирована из 1с ЗиК 7.7 конфигурация типовая пробовались разные типы баз - файловая, терминал и sql (windows server 2008. sql server 2008.) размер базы - 800Мб платформа и конфигурация обновляются регулярно. С базой работают 2 расчётчика Проблема в следующем: При одновременном расчёте заработной платы разным сотрудникам, у одного из расчётчиков(рандомно) возникает следующая ошибка: Ошибка: {ОбщийМодуль.ПроведениеРасчетовПереопределяемый.Модуль(4887)}: Ошибка при вызове метода контекста (Записать) НаборЗаписейРегистра.Записать(Истина, ТолькоЗапись, Истина, Ложь); по причине: Конфликт блокировок при выполнении транзакции: Microsoft SQL Server Native Client 10.0: Превышено время ожидания запроса на блокировку. В конфигураторе ссылается на следующую строку: Данная проблема возникает не только у нас. Фирма, которая осуществляет сопровождение сначала причиной называло медленный компьютер на котором стоит база (файловый вариант) или линии ЛВС(исключили эту причину сразу), базу перенесли на терминальный сервер - та же ошибка, на SQL то же самое. ЕСТЬ ли решение этой проблеме?

Все не так просто.

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

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

Конфликт блокировок в 99% случаях говорит об ошибках в алгоритмах доступа к данным. Если конфа типовая, обращайтесь в поддержку 1С.

Переписывать. Всё. Не дожидаясь перитонита.

файловая база стоит на обычном ПК (Dual-Core E5200, (2.50/800/2Mb); 2GB DDRII-800; Seagate (320 Gb/ 7200/8Mb/ SATA ). терминальный и sql сервер ещё на более древнем компе(1 гб ОЗУ), НО цитата: "Конфликт блокировок при выполнении транзакции" = Дедлок В данном случае повышение производительности не решит проблему, а только сделает вероятность ее возникновения меньше. Т.е. только отложит проблему на будущее

Переписывать что? поподробнее пожалуйста. Кстати, данная База 1с 8.2 ЗКБУ собиралась из 6 баз 1с 7.7 ЗиК, из которых 2 были не типовые с правленой конфигурацией. Переводили базу в течении 3-4 месяцев, до сих пор возникают ошибки в базе (конкретные примеры пока привести не могу), у расчётчиков очень много вопросов к сотрудникам фирмы, которая занималась переводом базы. Данный сотрудник и в данный момент приходит и что то доробатывает по преензиям наших расчётчиков

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

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

При расчете добавляются записи в регистр расчета, потом все считается. Раз конфликт возникает - значит считают одновременно одно и то же.

Фига се косметика... Это не косметика... Это хирургия уже... А вот более радикально - это уже реинкарнация будет... Исправление ошибок методом Ctrl-A - Del...

"Исправление ошибок методом Ctrl-A - Del..." Ещё скажи "Format c:" "значит считают одновременно одно и то же." Конфликт будет даже если один расчетчик заблокировал регистр для "заполнения", а другой попробует рассчитать. Тут явная проблема с алгоритмом проведения.

есть отличное решение - забить. зп считается не так часто, тем более расчетчика всего два.

>Данный сотрудник и в данный момент приходит и что то доробатывает по преензиям наших расчётчиков Ну вот и виновник нарисовался.

Пусть считают в разное время.

Ага, что-нибудь типа вопроса "Ну чо, проводим?" висит в обработке проведения или заполнения...

"Пусть считают в разное время." Правильно - один в первую смену, второй - во-вторую, ну а третий = ночью.. Ибо нефик.. Заодно на количестве компов сэкономят (все расчетчики могут считать на одном компе). ПыСы... Оптимизировать код - не предлагать

оптимизировать код ЗиК БУ - не предлагать точно

Расчет начислений в "бюджетном учреждении" нервно курит в сторонке перед расчетом начислений на крупном производстве с кучей сменных графиков и прочих нюансов одновременно.

Если "оптимизировать" = "выкинуть все костыли внедренцев", то очень даже стоит.

да что Вы?! видимо с медиками не работали... зарабатывающими медиками, а не поликлиническими

какие костыли внедренцев, если база типовая?

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

Ни факт что "типовая".. Читам у ТС "Кстати, данная База 1с 8.2 ЗКБУ собиралась из 6 баз 1с 7.7 ЗиК, из которых 2 были не типовые с правленой конфигурацией."

Судя по она совсем не типовая...

, а судя по - типовая. то, что в нее запихивали данные 6 разных баз, еще не означает снятия с поддержки. то, что Вы делали такие расчеты в ?ЗуП/УПП/КА дает Вам право говорить, что расчет в бюджете более легок?

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

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

+++ Уже одно только " Переводили базу в течении 3-4 месяцев, до сих пор возникают ошибки в базе" говорит о том, что база сейчас уже явно "не типовая".

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

а неправильно это как?то есть выползло сообщение и расчетчик забил?

Сколько сотрудников в базе?

400-500 чел. с сотрудников не брала налог при расчёте

Режим управления блокировкой данных для всей конфигурации установлен Управляемый (по умолчанию).

Это большая база. Без оптимизации кода твои расчетчики будут постоянно влетать в блокировки. Так что тут "или - или": Или ты меняешь свой существующий бизнес-процесс расчета под типовой (например переводишь расчетчиков в сменный режим работы", либо ты меняешь типовую конфу под особенности своей бизнес-логики.

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

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

Доступ на уровне записей используете? Если да - отключите.

"Каждую неделю выходят обновления, неужели эту проблему не могут решить производители ПП. " Именно для этого в штате и держат 1Сника или становятся на поддержку франчам. На самом деле "считать начисления" на такое количество сотрудников вполне может и 1 расчетчик. А работа расчетчика это не только "нажимать кнопку расчет", поэтому вполне можно перераспределить функции без ущерба для штатки (если лом подправлять конфу под свои особенности)

неа, не правы. в я всего лишь сказала, что переписывать расчетные конфигурации - дело очень неблагодарное. я бы такое и про ЗуП, и про расчетный блок в УПП сказала. Вы оптимизировали расчеты? исключили блокировки? ТС можете посоветовать к себе, например, за доработками обратиться?

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

здорово,а как связали бардак в и блокировки?телепат детектед

Да нет, просто внимательно прочли в "Конфликт блокировок при выполнении транзакции: "

купите нормальный сервер. а эту жесть выбросите на свалку

какая оптимизация? о чем вы говорите. на железо посмотрите. оптимизировать код и архитектуру выйдет на пару порядков дороже чем купить более менее нормальное железо с которым еще пяток лет париться об оптимизации не придется

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

"рлс отключить например" РЛС на регистр расчета в типовых никогда не ставится - не выдумывайте

договоритесь перенести к кому-нибудь на более мощный сервер свою базу и посмотрите будут блокировки или нет

"договоритесь перенести к кому-нибудь на более мощный сервер свою базу " Да-да-да.. конечно-конечно.. И заодно посадить своих расчетчиков на "чужой сервак", чтобы 100-пудово смоделировать ситуацию (и пусть поработают так месяца 2 для чистоты эксперимента)

В типовой УПП есть.

Вы оптимизировали расчеты? каким образом мы может их оптимизировать? исключили блокировки? тут непонятная ситуация. Перевёл базу sql на управляемые блокировки + регистр расчёта ОсновныеНачисленияРаботниковОрганизаций так же перевёл на управляемые блокировки. Результат тот же. НО в файловой базе 1 раз расчёт одновременно с 2 пользователей прошёл, далее о5 возникала блокировка уже на др документе "Документ.НачислениеЗарплатыРаботникамОрганизаций" - так же изменил - поставил для него режим упр. блокировок. не помогло ТС можете посоветовать к себе, например, за доработками обратиться? у нас договор с оф. представителем 1с на сопровождение, разве они не должны решать эту проблему?

Сколько идет расчет в случае 1 пользователя?

минимально-рекомендуемую конфигурацию пк-сервера какую посоветуете? P.s. по рекомендуемым требования к windows server 2008, sql server 2008, 1c 8.2 наши ПК-сервера подходят, хотя согласен устарели оч давно

не более 10-15 сек

попробую завтра поднять сервак на виртуалке, на более мощном компе. Вопрос есть ли смысл пробовать установить windows server 2003 и соответственно sql server 2003 ?

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

что для вас более мощный?

то есть по организации и физикам для вас нет?

Для этого надо попробовать увеличить время ожидания блокировки, допустим, до минуты. как увеличить в файловой базе до минуты время ожидания блокировки? В sql средствами самого sql i3-4130/4gb/1tb[7200об] примерно такой

купите вот такой всего 20т. и ваш зуп будет летать

В Конфигураторе Администрирование -> Параметры информационной базы.

на sql "управляемые блокировки" не помогли: Конфликт блокировок при выполнении транзакции: Microsoft SQL Server Native Client 10.0: Превышено время ожидания запроса на блокировку. HRESULT=80040E31, SQLSrvr: SQLSTATE=HYT00, state=2D, Severity=10, native=1222, line=1 увеличивать таймаут блокировки средствами sql пока не пробовал в файловом варианте: {Документ.НачислениеЗарплатыРаботникамОрганизаций.МодульОбъекта(1233)}: Ошибка при вызове метода контекста (Записать)     НаборЗаписейРабочееВремя.Записать; по причине: Конфликт блокировок при выполнении транзакции: попробую

управляемые блокировки?

увеличил время ожидания блокировки до 90 сек. Двое сотрудников одновременно рассчитали по 1 человеку, в sql варианте. В файловом варианте конфликт блокировок Имеется ввиду: Установка режима блокировок в конфигурации - на управляемые

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

есть 3 основных пути ухода от "блокировок": в вашем случае при катастрофической нехватки мощей и полном отсутствии компетенции в п.2 и п.3 - единственный вариант (причем самый менее трудо и финансово затратный в вашем случае) - это наращивание железа.

Нуф-Нуф, не мути воду, пусть переписывает код.

Вы по-моему путаете блокировки и взаимоблокировки. У ТС как раз последние. А от них наращиванием железа не уйти.

В файловом варианте блокируется вся таблица, так что, видимо, без клиент-сервера не обойтись.

чета не нашел в сообщение ТС про дэдлок ни слова, ожидание у него на блокировках.

Что-то я тоже теперь не нахожу. Это все запутал. :)

Похожая ситуация. Типовая УПП, несколько расчетчиков. Расчет з/п марта + одновременная работа с табелем апреля, даже по разным подразделениям = дедлок. Саппорт 1С пока отмазывается в стиле "это не баг, а фича"

> терминальный и sql сервер ещё на более древнем компе(1 гб ОЗУ) Это не сервер. Это смартфон. (с) кто-то из мистян. > файловая на обычном ПК (Dual-Core E5200, (2.50/800/2Mb); 2GB DDRII-800; Seagate (320 Gb/ 7200/8Mb/ SATA ) Для файловой в монопольном доступе это может быть и потянет. В сетевом доступе с одновременной работой пользователей с одними и теми же таблицами на запись - этого явно мало. > "Конфликт блокировок при выполнении транзакции" = Дедлок У вас явно проблема с ожиданием на блокировках. Учитывая, что конфа типовая и переписывание кода не рассматривается, то лечится только увеличением производительности железа. Возможны конечно еще и проблемы с самими данными, но удаленно об этом судить невозможно. Так что ИМХО, абсолютно правы > Фирма, которая осуществляет сопровождение причиной называло медленный компьютер на котором стоит база Из опробованных вами вариантов - файловый вариант можно рассматривать, если только база будет вертеться на нормальном производительном файловом сервере (НЕ на обычном компьютере в сети, а именно на полноценном настроенным сервере) - клиент-серверный вариант однозначно не на том железе, которое вы по какому-то недоразумению называете сервером. И на этом сервере ничего не должно быть кроме СУБД и 1С (никаких почтовых серверов, терминальных, контроллеров домена и прочих служб и сервисов).

> Это не сервер. Это смартфон. (с) согласен. "Смартфон" за неимением более производительного ПК был использован для пробы, как поведут себя блокировки в клиент-серверном варианте. P.s. по рекомендуемым системным требованиям (со слов поддержки) используемых программных продуктов и ОС, на "смартфоне" должно всё хорошо работать. хотя вариант с сервером терминалов здесь нецелесообразен в связи с более худшим железом на "смартфоне", чем на ПК пользователей. ssd есть смысл покупать-ставить или использовать стандартные HHD для сервера? В ближайшее время, если будет возможность, купим "полноценный" сервер. По результатам обязательно отпишусь.

У вас ФАЙЛОВАЯ база, переключаться между автоматическим и управляемым режимом блокировок бесполезно. В файловом варианте блокируются таблицы целиком. В вашем случае выход один - считать зарплату в монопольном режиме

всего 14 400 руб.... и скуль бесплатный...

> В вашем случае выход один - считать зарплату в монопольном режиме не вариант в монопольном. есть второй выход: купить норм железо-сервер. ИМХО не совсем в тему ссылка, если я правильно понял. Из моего 0 поста следует, что у нас уже имеется MS SQL Server 2008, сервер 1С:Предприятия 8.2, клиент-серверная версии 1С: Предприятие 8.2

блин, тут остались вообще спецы или нет? неужели только я один вижу что на "еще более древнем чем (Dual-Core E5200, (2.50/800/2Mb); 2GB DDRII-800; Seagate (320 Gb/ 7200/8Mb) и с 1Гб ОЗУ)" ничего сделать нельзя. ну нет тут предметного разговора.

да да ты один супер крут, может ветку почитаешь?

а что там?

читай еп )) человек хочет задрочить базу блокировками в файловом режиме, пусть дальше терзает

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

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

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

а какие выводы сделаны, если не секрет?

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

еще один

ты бы еще сказал ЦУП развернуть, профайлер посмотреть.

+ уже говорил :)

Ну помочь вроде хотим же.

чем поможешь неадеквату?

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

ахахаха, всех обо$рал и все равно сделал как ему сказали

аааааа! спасибо. камень с души упал. а думал ваще безнадега.

Ну вот, а говорили безнадега,неадекват.

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

возможно, но Вы не хотите регламентировать работу расчетчиков.

кстати вариант.