Коллеги, у клиента с завидным постоянством возникает ошибка:
Конфликт блокировок при выполнении транзакции: Не удалось заблокировать таблицу '_DOCUMENT***'»

Конфа УТ 10.3.8.9, платформа 81.15.14, 2 лицензии, файловый вариант, работа ведется с двух компов в локальной сети, 2-ой комп подключается к базе через сетевой диск (папка с базой на 1-ом коме расшарена)

Ошибка возникает когда на обоих компах одновременно проводятся документы.
Тестирование и исправление не помогло.
Тестирование и исправление с отметкой "реструктуризация таблиц инф. базы" привела к ошибке работы процедуры, и обработка зависла... навсегда... :(
Чекдбфл - не помог.

Буду очень рад Вашим предложениям и "делением" опытом в решении этой проблемы :)
Заранее благодарен.

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

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

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

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

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

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

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

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

(0) Конфа типовая?

>> когда на обоих компах одновременно проводятся документы.

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

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

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

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

Для двух пользователей? Ну, ну...

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

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

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

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

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

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

(9) конфа типовая

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

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

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

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

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

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

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

Вот выдержка из одного форума:

ХХХ - В последнее время после 14 часов выдает ошибку "Конфликт блокировок при выполнении транзакции. Не удалось заблокировать таблицу _AccntReg5577"
Как это лечиться?

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


ХХХ - походу действительно так. пережал базу - ошибка пропала.

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

(23) http://1c.proclub.ru/modules/newbb/viewtopic.php?viewmode=flat&topic_id=290881&forum=10

(23) http://odines.ru/thread1386.html

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

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

(29) это было сказано еще в (19)

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

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

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

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

Ну или расскажи почему ТиИ с реструктуризацией выдает ошибку. Или это типа нормально.

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

Ведь в указанной вами цитате речь идет о регистре сведений а не о таблице документов?

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

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

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

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

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

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

(37) я понимаю что это не ошибка, а обработка платформой конфликта блокировки.
я хочу избавиться от этого конфликта.
вот еще ссылка на обсуждение подобной проблемы, и там тоже есть изложенные в (0) рекомендации:
http://forum.nov.ru/index.php?showtopic=244886

(36) Ну если только это, то, вроде как, отношения к обсуждаемой проблеме это не должно иметь.

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

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

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

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

То что вам реально может помочь
http://v8.1c.ru/metod/books/book.jsp?id=63
Глава 4 и 5.

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

Вариантов много, зависит от конкретной задачи. В любом случае стратегия на разделение ресурсов.

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

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

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

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

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

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

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

то есть (47)

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