Ошибка: Конфликт блокировок при выполнении транзакции: Не удалось заблокировать #518256

Коллеги, у клиента с завидным постоянством возникает ошибка: Конфликт блокировок при выполнении транзакции: Не удалось заблокировать таблицу '_DOCUMENT***'» Конфа УТ 10.3.8.9, платформа 81.15.14, 2 лицензии, файловый вариант, работа ведется с двух компов в локальной сети, 2-ой комп подключается к базе через сетевой диск (папка с базой на 1-ом коме расшарена) Ошибка возникает когда на обоих компах одновременно проводятся документы. Тестирование и исправление не помогло. Тестирование и исправление с отметкой "реструктуризация таблиц инф. базы" привела к ошибке работы процедуры, и обработка зависла... навсегда... :( Буду очень рад Вашим предложениям и "делением" опытом в решении этой проблемы :) Заранее благодарен.

Переводить базу в клиент-сервер.

"Ошибка возникает когда на обоих компах одновременно проводятся документы." - отсюда ноги растут

Файловый режим не предназначен для паралельной работы.

Мда... точнее нужно со словами

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

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

а диск случайно не внешний usb ?

2(1,3) Ну-ка расскажите как клиент-серверный режим избавляет от блокировок. В чем суть механизма.

Конфа типовая? >> когда на обоих компах одновременно проводятся документы. Какие документы (любые/какие-то конкретные) и как проводятся (интеративно/групповой обработкой)?

+ к Имя таблицы именно так и выглядит '_DOCUMENT***' ?

В файловой сразу вся таблица блокируется, а в клиент-серверном варианте СУБД несколько мягче все это делает :)

>> Файловый режим не предназначен для паралельной работы. Для двух пользователей? Ну, ну...

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

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

2 так отож.. А ему сразу советуют(может неявно, но все-таки) начать тратить деньги.

уверенно сказать не могу... но по-моему нет, не усб

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

"так отож". Наверно эти два юзера и написали. Коллективнымм разумом.

конфа типовая на одном компе проводятся доки реализация товаров и услуг, на втором компе запускается внеш обработка, которая из заказов покупателей лепит и проводит доки "реализация товаров и услуг" имя таблицы '_DOCUMENT213' - ну т.е. в место зведочек цифры :), иногда ругается на таблицу "ЖурналДокументов" (DocumentJournal - как-то так)

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

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

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

покажите ссылку?

Вот выдержка из одного форума: ХХХ - В последнее время после 14 часов выдает ошибку "Конфликт блокировок при выполнении транзакции. Не удалось заблокировать таблицу _AccntReg5577" Как это лечиться? УУУ -Возможно это связано с возрастающей загрузкой сети. На форумах по 1С встречался мне подобный материал. К сожалению не могу сейчас его найти и дать вам ссылку. ХХХ - походу действительно так. пережал базу - ошибка пропала.

а если воспользоваться мозгом? Иногда это лучше гугла.

при всем моем уважении - воспользуйтесь сами своим советом, и напишите что-нибудь по теме

21) ну так чего пишете, что типовая, если у вас работает явно нетиповая обработка, которая наверняка на полдня захватывает все документы реализации, и которая наверняка написана коллективным разумом выеуказанных двух юзеров?

это было сказано еще в

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

при всём моём уважении - из вопроса ясно, что его автор абсолютно не понимает механизма блокировок платформы 1С.  Почитайте теорию.

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

ОФФ. Послушай, уважающий. Лучше бы чего-нибудь дельного сказал, чем многозначительные фразы кидать о том, что кругом все идиоты и не в теме. Ну или промолчал бы. Ну или расскажи почему ТиИ с реструктуризацией выдает ошибку. Или это типа нормально.

2 ну хорошо... А почему вы подумали что вам подойдет именно этот совет, а не например, взять за основу это объяснение? "Простейший пример возникновения: одна транзакция накладывает блокировку на таблицу БД, а вторая на другую, но для продолжения работы первой транзакции нужна та таблица, на которую наложила блокировка вторая, а для продолжения работы второй - наоборот. Очевидным образом такие взаимоблокировки неразрешимы и после определенного таймаута, как правило, сервер БД выдает ошибку." Ведь в указанной вами цитате речь идет о регистре сведений а не о таблице документов?

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

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

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

2 "провести параллели " - уж если вы выдумываете новый термин в конфо-строении, то не сочтите за труд - дайте ему определение...

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

Ну если только это, то, вроде как, отношения к обсуждаемой проблеме это не должно иметь. Тогда надо разбираться как именно возникают блокировки. Либо там действительно большие документы или пользователи вводят их с такой скоростью, что блокировки для них нормальное явление, либо где-то железо/сеть тупит, либо... Честно говоря видел достаточно конторок, ведущих учет на файловой УТ с количеством пользователей до 10 человек. Блокировки конечно иногда появляются, но случается это достаточно редко. Но вот чтобы два пользователя постоянно не могли одну таблицу поделить... Ну и остается проблема с ошибкой ТиИ с реструктуризацией. Такого быть не должно. С этим что-то надо делать. Пытаться выгрузить/загрузить базу, делать ТиИ chkdbfl.

Это обсуждается изо дня в день и  на этом форуме... (например: Но для того чтобы что-то научиться решать в этом вопросе..Я считаю мало читать обсуждения.. Потому что постоянно в этих обсуждениях будешь попадать в тупиковые ветки типа той, как вы уже попали, попытавшись решить проблему при помощи ТиИ... То что вам реально может помочь Глава 4 и 5.

проблема, указанная в топике, решается разделением использования ресурсов. Есть несколько способов реализации: 1. Разделение обработок по времени - запускать обработку когда документы не проводят. 2. Уменьшение пространства блокировок - переписать обработку формирования так, чтобы в один промежуток времени обрабатывалась только небольшая часть документов. Вызывать обработку циклически например регламентным заданием. Файловую базу необходимо перевести в серверную - SQL лучше работает с блокировками (блокирует диапазон записей, а не таблицу как файловая версия). 3. Разделить по времени проведение по регистрам - механизм отложенных движений (см. типовую конфигурацию). Вариантов много, зависит от конкретной задачи. В любом случае стратегия на разделение ресурсов. "Ну или расскажи почему ТиИ с реструктуризацией выдает ошибку. Или это типа нормально." - а вот это не понял о чём. Если вы имеете ввиду _AccntReg5577, то тут скорее всего речь об итогах, которые в 1С записываются в физические таблицы с разделением, и реструктуризация приводит приводит к пересчету итогов и  свертке разделенных записей. А чем меньше записей в таблицах, тем меньший диапазон записей будет блокировать SQL и ситуация с блокировками в целом немного улучшиться.

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

при ТиИ с пометкой "реструктуризация" выдает вот такое сообщение: ------------- В процессе обновления информационной базы произошла критическая ошибка. по причине: Ошибка СУБД: Ошибка SQL: Запись значения NULL в поле, не допускающее NULL '_FLD2437_TYPE' по причине: Ошибка SQL: Запись значения NULL в поле, не допускающее NULL '_FLD2437_TYPE' ------------- тестирование физической, логической целостности и чекдбфл эту ошибку не исправили... я конечно прямой связи с конфликтом блокировки здесь не вижу, но для начала думаю надо избавиться от этой ошибки

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

я сделал стандартным способом выгрузку данных(конфигуратор-администрирование-...), затем загрузил её в пустую конфу, эта процедура ошибку оставляет?

2 легко ведь проверить, какая разница что я отвечу.

то есть

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