Как побороть "Не удалось заблокировать таблицу..." при проведении.

Форум Учет и отчетность Торговый учет, опт и розница (Торговля)

1С:Розница 2 Платформа 1С v8.3

1. Alis95 21.07.14 11:47 Сейчас в теме

Здравствуйте, уважаемые форумчане!
Розница 2.1.2.8 на 1С:Предприятие 8.3.4.482. Файловый.
Win8.1 x86.

При сохранении или проведении документов, а так-же пробитии чеков в РМК, иногда, с разной периодичностью (раз в месяц, иногда даже 3 раза в день), появляется сообщение: "Не удалось заблокировать таблицу '_AccumRg3919'. В этот момент документ не сохраняется, повторная попытка сохранить/провести - удачная; что касаемо чеков из РМК при появлении этого сообщения, на фискальнике (вернее ПД) чек - пробиваются, в 1С - нет.
Последний раз при закрытии смены появилось: "Не удалось заблокировать таблицу '_DocumentChngR1681'" с вытекающими из этого последствиями.

P.S. Включено выполнение регламентных заданий (всё по умолчанию + сценарий синхронизации по магазину РИБ раз в 30мин.). Пока копаю журнал регистрации, может что с этим связано...

Вопрос: По какой причине "Не удалось заблокировать таблицу..."? Что это может быть и где копать?

Заранее крайне благодарен!

Ответы

Подписаться на ответы Инфостарт бот

Свернуть все

2. Xatori111 18 21.07.14 11:55 Сейчас в теме

(1)Таблица заблокирована кем то ранее.

3. asved.ru 37 21.07.14 12:01 Сейчас в теме

Это как раз РИБ и виноват.

Проводимый документ пытается писать в _DocumentChngR1681 факт своего изменения, чтобы зарегистрироваться к обмену в РИБ. А при этом происходит чтение данных для выгрузки, блокирующее внос новых изменений. Это by design, либо смиритесь, либо откажитесь от РИБ.

4. Alis95 21.07.14 15:18 Сейчас в теме

Спасибо огромное за подсказку!
Просмотрел 5 последних сбойных чеков (кстати они в Рознице записываются непроведёнными в "Чеки ККМ", без статуса с правильной датой и временем 00:00:00). В журнале регистрации, действительно эти сбойные чеки пробивались во время выполнения сценария обмена по магазину.

Вопрос_1: А не существует ли каких-либо обработок, которые бы предупреждали пользователя о начале синхронизации, не давая выполнить действие до её завершения?
А то получается не очень удобно (например, с чеками, на фискальнике пробивается, а в 1С - нет).

Или синхронизировать только вручную?

Вопрос_2:
Помимо выполнения сценариев синхронизации, какие-то ещё могут препятствовать?

Заранее спасибо.

5. DJDUH 17 21.07.14 16:10 Сейчас в теме

(4) Alis95, руками синхронь)

6. asved.ru 37 21.07.14 17:13 Сейчас в теме

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

На _DocumentChngR1681 - только обмен.
На _AccumRg3919 - любая другая транзакция.

Вообще лечить нужно причину, а не следствие. Архитектурно как система построена? Судя по таймауту на блокировке _AccumRg3919 (основной таблице регистра накопления), база файловая? Покупайте сервер.

13. zoytsa 23.07.14 17:59 Сейчас в теме

(6) asved.ru,
Представьте, если у Вас обмен "подвиснет" на несколько минут, то и флаг будет держать кассу. А это не хорошо. :-)
Уменьшение элементов в транзакции должно быть достаточно. :-)
Ну, и сервер бы...

15. asved.ru 37 24.07.14 05:55 Сейчас в теме

(13) zoytsa, если не будет флага - кассу будет держать заблокированная таблица регистрации изменений.

16. Alis95 24.07.14 08:30 Сейчас в теме

(15) А можно по подробней по поводу флага?

У меня (до изменения количества транзакций с "0" до "1", после - ещё не известно), если пробитие чека происходило в момент синхронизации, в Рознице чек не пробивался и сохранялся как чек без статуса непроведённый, с правильной датой, но временем 00:00:00, + получал сообщение в РМК "Не удалось заблокировать таблицу...", а на фискальнике пробивался. Как следствие, данные фискальника начинали разниться с Розницей.

17. zoytsa 24.07.14 14:10 Сейчас в теме

(15) asved.ru,
Здесь вопрос в том, чтобы флаг включать именно при блокировке таблицы, а не при начале обмена, верно?
Вероятность блокировки при количестве элементов на транзакцию установленном в 1 - очень не большая.
А вот то, что обмен остановит кассу при топорном флаге - 100 %. :-)

18. asved.ru 37 24.07.14 14:18 Сейчас в теме

(17) zoytsa,

Вероятность блокировки при количестве элементов на транзакцию установленном в 1 - очень не большая

Вероятность блокировки при количестве элементов на транзакцию установленном в 1 равна 100%. Блокировка накладывается в любом случае.

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

Поэтому ошибку таймаута на блокировке мы почти гарантированно не получим.

19. zoytsa 24.07.14 14:56 Сейчас в теме

(18) asved.ru,
Да, именно так. :-)

7. Alis95 21.07.14 19:21 Сейчас в теме

...база файловая?

Она самая.

Покупайте сервер.

Пока не вариант.

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

Всем спасибо а участие и помощь.
Если будут ещё какие предложения, буду рад услышать.

8. asved.ru 37 22.07.14 06:11 Сейчас в теме

(7) Alis95, подумайте о http://www.1c.ru/news/info.jsp?id=17577

9. МимохожийОднако 142 22.07.14 06:27 Сейчас в теме

Обмен с РИБ для розницы достаточно настроить один раз в день ночью. Нет смысла каждые полчаса делать обмен. ИМХО.

10. Saint64Rus 23.07.14 12:23 Сейчас в теме

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

22. Alis95 24.03.18 22:01 Сейчас в теме

Новая Розница 2.2.7.37, проблема старая (это уже другая БД, но проблема такая-же, посему апну старую тему).

РИБ с сценариями автоматического обмена каждые 30 мин. всего 4 узла (главный и 3 подчинённых).
Если пробитие чека попадается на момент выполнения сценария синхронизации, иногда получаем пробитый чек на ФР и не пробитый чек в рознице из-за конфликта блокировок.

(10) В этой Рознице 2.2.7.37 настроек по количеству элементов транзакции не обнаружил. Хотя и на 2.1.2.8 это не решало проблему полностью, а только заметно снизжало количество конфликтов блокировок.
Появились способы разрулить данную проблему?

Заранее крайне благодарен!

23. Alis95 27.03.18 16:32 Сейчас в теме

Del

11. Alis95 23.07.14 16:28 Сейчас в теме

Да, в 1-ой (т.к. значение не указано).
Спасибо за совет! Попробую.
Но на всякий случай уточню этот момент... Если "Элементов в транзакции" поставлю "1", это никак отрицательно не скажется на РИБ'е? На корректность синхронизации?

12. asved.ru 37 23.07.14 17:10 Сейчас в теме

(11) Alis95, никак. Это скажется только на производительности процесса синхронизации.

14. Alis95 23.07.14 23:57 Сейчас в теме

Всем большое спасибо за подсказку!
Поставил количество элементов транзакций загрузки и выгрузки "1" на всех машинах. Произвёл обмены, пока всё штатно. Буду смотреть дальше, будут ли обломы при пробитии чеков и других проведениях документов.
Как я понял, чем меньше элементов, тем дольше обмен, но меньше вероятность блокировок таблиц?

С сервером - взял на заметку, но пока воздержусь (по крайней мере в этом году).

20. Tolya_74 17.05.16 12:23 Сейчас в теме

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

21. lenochka-semicova 18.05.16 22:16 Сейчас в теме

(20) Все зависит от того, с чем сервер приготовить.

24. Alis95 27.03.18 16:36 Сейчас в теме

Новая Розница 2.2.7.37, проблема старая (это уже другая БД, но проблема такая-же, посему апну старую тему).

РИБ с сценариями автоматического обмена каждые 30 мин. всего 4 узла (главный и 3 подчинённых).
Если пробитие чека попадается на момент выполнения сценария синхронизации, иногда получаем пробитый чек на ФР и не пробитый чек в рознице из-за конфликта блокировок.

[10] В этой Рознице 2.2.7.37 настроек по количеству элементов транзакции не обнаружил. Хотя и на 2.1.2.8 это не решало проблему полностью, а только заметно снизжало количество конфликтов блокировок.
Появились способы разрулить данную проблему?

Заранее крайне благодарен!

25. oxed 05.10.18 11:52 Сейчас в теме

(24) Столкнулся с той же бедой. Нашли какие-то решения?

26. Alis95 05.10.18 15:18 Сейчас в теме

Нет. Пока только регулярно устраняю последствия. Как правило, проблема создаёт головную боль с чеками (чек пробивается на ККТ, а в 1С - нет). Приходится перенастраивать в справочнике "Кассу ККМ" в 1С на "Без подключения оборудования", пробивать чек в 1С, затем снова перенастраивать на ККТ. В случае неудачного открытия смены (в момент синхронизации), закрывать смену через тест-драйвер и снова открывать в 1С.

35. Rans 7 08.02.19 14:43 Сейчас в теме

(26) Проще через групповую обработку и в главной базе

27. vacony 24.10.18 09:21 Сейчас в теме

Большая сеть. Эта проблема регулярная. Кассы - Атол и Пирит .
Проблема не решена, частично ускоряется обработкой что ставит статус чекаКккм - пробитый , если в кассу пробилось, а в 1С нет.

Вопрос - в конфе есть общая константа количество элементов в транзакции , и есть два параметра в обменах - транзакция на отправку и на получение.
В чем разница ?
И пробовали их менять ?

Да, базы файловые, 2.2.9.20 , платформа 8.3.12 , базы от 4 до 9 гиг., магазинов около 100, касс 200., обмен 15 минут автомат везде.

28. tezdal 29 13.12.18 14:27 Сейчас в теме

(27) столкнулись с той же бедой, не поделитесь советом по решению проблемы?

29. vacony 14.12.18 09:39 Сейчас в теме

(28) о какой именно проблеме речь? )

П.С. изменение общей константы транзакций благотворно влияет на работу. ошибки блокировки таблиц обмена (node21 ) исчезли на 99%.

30. tezdal 29 14.12.18 14:16 Сейчас в теме

(29) Константа установлена и равна 1. Но при печати чека с переодичностью раз в час возникает конфликт блокировок. Основные проблемы с регистром сведений АкцизныеМаркиЕГАИС
Смотрю код и пытаюсь понять в чем беда

33. user1038092 31.01.19 19:58 Сейчас в теме

(29)Это где нужно менять.
Подскажи, пожалуйста!

31. vacony 27.12.18 17:24 Сейчас в теме

А полный текст ошибки можно ?
Ошибка на кассе - это риб по месту или магазину ?
Как часто стоит обмен и обмен куда - локально или на удаленный FTP ?

32. user1038092 31.01.19 19:56 Сейчас в теме

Коллеги, привет!
Та же тема!

Что подскажите?

Запись чека не выполнена по причине:
{Обработка.РМКУправляемыйРежим.Форма.Форма.Форма(10451)}: Ошибка при вызове метода контекста (Записать): Ошибка при выполнении обработчика - 'ПередЗаписью': {ОбщийМодуль.ОбменДаннымиСобытия.Модуль(1055)}: Не удалось зарегистрировать изменения на узлах плана обмена ПоМагазину по причине: {ОбщийМодуль.ОбменДаннымиВызовСервера.Модуль(168)}: Ошибка при получении значения атрибута контекста (ДатаОбновленияПовторноИспользуемыхЗначенийМРО)
Если ПараметрыСеанса.ДатаОбновленияПовторноИспользуемыхЗначенийМРО <> АктуальнаяДата Тогда
по причине:
{ОбщийМодуль.ОбменДаннымиСервер.Модуль(7938)}: Ошибка при вызове метода контекста (Выполнить)
Возврат Запрос.Выполнить().Пустой();
по причине:
Ошибка выполнения запроса
по причине:
Конфликт блокировок при выполнении транзакции:
Не удалось заблокировать таблицу '_NODE21'
по причине:
Не удалось заблокировать таблицу '_NODE21'

Показать

34. Rans 7 08.02.19 14:35 Сейчас в теме

Присоединяюсь к вопросу.
После обновления розницы на релиз 2.9.11.24 при синхронизации стал ловить такие сообщения "Не удалось заблокировать таблицу '_NODE21'".
Обмен раз в 15 минут через фтп.
Реже делать смысла нет - накапливается много данных, чаще тоже - если затык или файл большой, то файл будет обновляться чаще чем клиент его сможет принять.
_NODE21 это таблица плана обмена по магазину, в 2.2.7 конкретно такой ошибки раньше не было, но чеки иногда тоже не пробивались из-за блокировки.
Константу установил в значение 1, эффекта нет.
Из идей пока только попробовать софт для синхронизации файлов обмена, а в 1С уже переделать обмен на локальный ресурс.

38. VodoleyPlus 15.03.19 10:24 Сейчас в теме

(34)

бки раньше не было, но чеки иногда тоже не пробивались из-за блокировки.
Константу установил в значение 1, эффекта нет.

Такая же проблема возникла после обновления на 2,2,11,29 появилась. Хотя раньше работал обмен каждые 5 минут и мы не замечали.
При чем у нас в Рибе только ошибки, на основной базе проблем нет ...

Вам свою проблему удалось побороть?

39. Rans 7 15.03.19 14:14 Сейчас в теме

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

Да и на основной базе ошибок и не должно быть если она серверная.

40. VodoleyPlus 15.03.19 15:20 Сейчас в теме

(39)

Да и на основной базе ошибок и не должно быть если она серверная.а

Не понял вот это. Базы же одинаковые. Включился процесс синхронизации и из-за этого база блокирует пробитие других документов, разве это не одинаково должно работать на РИБ и Серверной?

41. Rans 7 19.03.19 10:53 Сейчас в теме

(40) Узел же файловый. Блокировками управляет субд 1с. На серверной блокировками на уровне таблиц управляет, к примеру, ms sql server. Поэтому работает по-разному. Если, конечно, под "серверной базой" вы подразумеваете базу развернутую на сервере 1с предприятия, а не просто файловый главный узел РИБ на сервере-компьютере. Плюс на сервере обычно железо круче.

42. VodoleyPlus 19.03.19 11:55 Сейчас в теме

(41)

на сервере-компьютере

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

44. vacony 27.08.19 10:26 Сейчас в теме

(34)

ODE21'".
Обмен раз в 15 минут через фтп.

Странно . у нас обмен так же и бегает, 15 минут, но таких проблем не наблюдаю...

Вы константу не 1 ставьте - это 1 блок в синхроне, а опытным путем найдите оптимальное для вас значение. Может и 10 и 100. Смотря сколько данных уходит.
Чем она меньше - тем быстрее будет обмен и лочиться другие таблицы, но чащу будет блочbться именно таблица обмена - node21
А чем она больше - наоборот...

36. coolseo 80 10.02.19 14:31 Сейчас в теме

А зачем вам обмен раз в минут? Делайте обмен ночью или по времени например 11.45 и т.д.
Мы так вышил из ситуации 5 узлов полный обмен, по времени поставили.

37. Rans 7 12.02.19 14:57 Сейчас в теме

Периодически обновляется информация о заказах, ценах, перемещениях, остатках итп. Кроме того был случай, когда наличие в цб актуальной информации помогло восстановить узел. Наверное, Вы правы, только удручает необходимость подстраивать бизнес-процессы под программу, а не наоборот.

43. smurf2315 21.03.19 10:32 Сейчас в теме

(37)

Вы правы, только удручает необходимость подстраивать бизнес-процессы под программу, а не наоборот

:) Ну это же логично - вы берете типовой продукт за недорого, он ограничен определенными бизнес-процессами; либо вы разрабатываете свой продукт "под себя" но цена вопроса заметно выше.

(37)

Периодически обновляется информация о заказах, ценах, перемещениях, остатках итп

На мой взгляд, наоборот, тут требуется отсутствие анархии, и работа по четкому расписанию (пример: к 14 часам подготавливаем новые товары и цены и передаем, магазин принимает обмен в 15 и готовит новые ценники и раскладку, в конце дня или утром принимает все изменения), а то бывают случаи когда новая цена уже прилетела а персонал еще даже не знает и ценники старые.

(37)

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

Для сохранения информации есть механизмы архивирования не в 1С, может быть теневое копирование windows например.

45. user1300344 24.10.19 16:48 Сейчас в теме

Подскажите, а где устанавливать количество элементов для транзакции?

46. vacony 23.01.20 11:01 Сейчас в теме

подниму старую. тему. чисто для информации.
на данный момент в базе бегает примерно 120 РИБ по магазину + 2 бухи.
синхрон каждые 15 минут. полет нормальный.
база на sql , размер примерно 550 Гиг, активных юзверов около 50-60.

47. venornik 01.07.20 04:48 Сейчас в теме

(46) как добились такого эффекта? если можно поподробнее

48. vacony 17.07.20 23:11 Сейчас в теме

(47) не совсем понял вопрос. в чем сложности ? )
затыки были только в создании риба, давно перешли на создание риба от "пустого " узла.
обмен бегает, все штатно, настроено как обычно. ftp. в отправке только чуть изменили хождение цен.
для уменьшения блокировок уменьшили размеры транзакции до 10 позиций.
сейчас 2.3.4.33 , 800 гиг база, около 100 юзерей.
напряжно еще обновляться только .. )

49. venornik 18.07.20 01:05 Сейчас в теме

(48)Пришли пожалуйста в личку свои контакты, если можно

52. vacony 09.12.20 15:32 Сейчас в теме

(49) да я тут на форуме живу.. )

50. DeN_FG 02.12.20 14:41 Сейчас в теме

(48)где уменьшили размер транзакции? Меняли константу количество элементов транзакции загрузки данных - блокировки так же появляются при прибытии чеков, затем не возможно закрыть смену так как 1с думает что чек не пробит

54. vacony 09.12.20 15:34 Сейчас в теме

(50)

см. ниже ответил

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

51. sh0p3n 09.12.20 10:30 Сейчас в теме

(48)
Подскажи пожалуйста, где менял размер транзакции?
В константе КоличествоЭлементовВТранзакции?
Пробовали менять в конфигурации 2.3.3.31, не помогает

53. vacony 09.12.20 15:33 Сейчас в теме

(51) да все верно

Попытка
УстановитьПривилегированныйРежим(Истина);
Константы.КоличествоЭлементовВТранзакцииЗагрузкиДанных.Установить(10);
УстановитьПривилегированныйРежим(Ложь);
Исключение
КОнецПопытки;

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

55. sh0p3n 09.12.20 16:53 Сейчас в теме

(53) Спасибо!

56. Funtik 26.08.21 12:29 Сейчас в теме

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

Оставьте свое сообщение

E-mail: