Добрый день
1С Розница , 2.3.5.35 , 8.3.15.1985 . Много РИБ по магазину. Обмен каждые 15 минут.
На продаже много алкоголя. При пробитии - идет запись справочника ПрисоедиенныеФайлыЕгаис и двоичные данные в регистр.
Проблема , что когда попадаем на обмен - получаем есс но ошибку блокировки. И данные про ответ ЕГАИС о пробитии бутылки не входит в базу...
Предприняли попытку программно отключить выполнение обмена при блокировке. Т.е. если при пробитии натыкается на блок, то среди фоновых находит обмен - и отменяем. Внешне все красиво, и по истории четко видно что задание обмена - Отменено пользователем и время завершения стоит как раз когда отмена.
НО запись дальше не происходит - блокировка таблиц остается..
Как можно это скинуть , отпустить блок таблиц ?
п.с. была мысль пытаться сохранить данные в файл, что бы потом записать в базу... но в той процедура в транзакции пишется и справочник, и двоичные и еще версии... крайне сложно все это сохранить кучкой
файловые на узлах. Управляемые блокировки работают только в клиент-сервере. Но в любом случае таблица регистрации изменений что в файловой, что в клиент серверной всегда использует табличную блокировку.
По блокировкам не соглашусь - т.к. в приложении можно что управляемые - что накладывают блок на таблицу для сохранения целостности, что ручные...
Но суть не в том. Вопрос методом тыка решился - если снимать задания в само начале процедуры - потом проверить что снялось , то далее все идет нормально.
А вот если сперва пробовать записать объект , и если не вышло - снимать фоновое и записывать объект заново - то задание снимается , но объект. записать() падает по блокировке , хоть 30 минут пробуй записать )
Интересная штука ... вы цеплялись к штатной выгрузке, заворачивали в хранилище текущий статус (шаг, и т.д.) и На клиенте - на форме - ловили ?
штука несомненно полезная, особенно если кассир будет смотреть. Но она увы не решает окончательно проблему..
Т.е. кассир если начал набивать товар, тут пошла строка.... ему "тормозить" минуту, две, пять пока обмен идет и смотреть на покупателя ? )
Эту штуку обязательно как то реализую в нашей сети. Но она помощник, не решение...
Хотелось бы либо свести блокировку не по таблицам. Либо вариант сбросить блокировку вообще с заданием. Но пока не пойму, почему Фоновое.Отменить() отменяет задание, но блок еще остается... даже паузу делал после отмены 5 сек , не всегда помогает... Видимо еще зависит сколько объектов были в транзакции. Обмен весь проходит в рамках одной транзакции, видимо для отката надо относительно много времени...
(12)Там один пользователь. Проблема блокировок в РИБе от количества пользователей не зависит. При выгрузке в РИБ всегда накладывается табличная блокировка на таблицу регистрации изменений.
(19) ну это почти равносильно созданию своего обмена ..
что то менее затратное есть ?
да и все равно - факт обмена сам, наличие таблиц регистраций изменений, куда пишутся изменения объектов, эти таблицы будут блочиться в любом случае, не важно от своего алгоритма обработки...
Свой алгоритм это в принципе свой набор правил только
(22)Это равносильно получению нужного объекта к передаче и его сериализация <> созданию своего обмена.
С помощью типового функционала передавать только изменения конфигурации.
Таблицы регистрации изменений блочатся только при использовании типового объектного метода выгрузки измененных объектов в файл. Вам не нужны правила, от слова совсем, т.к. это РИБ.
(26)Это справедливо для таблиц данных, а не таблиц регистрации изменений. Таблица регистрации изменений всегда блокируется целиком для обеспечения целостности выгружаемых для обмена данных.
и уже в управляемых можно хоть таблицу, хоть записи
У вас базы файловые на узлах. Управляемые блокировки работают только в клиент-сервере. Но в любом случае таблица регистрации изменений что в файловой, что в клиент серверной всегда использует табличную блокировку.
файловые на узлах. Управляемые блокировки работают только в клиент-сервере. Но в любом случае таблица регистрации изменений что в файловой, что в клиент серверной всегда использует табличную блокировку.
По блокировкам не соглашусь - т.к. в приложении можно что управляемые - что накладывают блок на таблицу для сохранения целостности, что ручные...
Но суть не в том. Вопрос методом тыка решился - если снимать задания в само начале процедуры - потом проверить что снялось , то далее все идет нормально.
А вот если сперва пробовать записать объект , и если не вышло - снимать фоновое и записывать объект заново - то задание снимается , но объект. записать() падает по блокировке , хоть 30 минут пробуй записать )
Пока надо задуматься о блокировке )
Не понятно момент - когда снимаются блокировки в таблицах в файловой базе, при отмене фонового задания
Или может я еще что то не знаю
Просто обмен идет порой 2-4 минуты.. Ставить попытку записи в цикл, пока не запишется - очень не хочется, очень некрасиво ...
Да и это будет - стоять покупатель 3-4 минуты ждать пробития..
(5) вы мне метод - про управление блокировкой при отмене фонового уточните если знаете )
т.к. "оптимизация, исправления и т.д. это не констуктивно " :)
(8) перво еэто теория фоновых, спасибо знаю ) та мответа нет
а приз - это статья 13 года, про другую платформу вообще, не УФ , и задача выгрузка одновременная ) А не блокировка на приемке...
Но спасибо за попытку )
1. Если много РИБ, переводите на клиент-серверный вариант.
2. Переписывайте правила обмена, чтоб уменьшить файлы, выкидывайте из них марки, справочник штрих-кодов упаковок, справок 1 и 2, и др. Это не нужно в ЦБ, Причем эти данные из ЦБ, полностью попадают в РИБы. (в других магазинах есть справки и др. которые должны быть только в одном)
не вариант никак. это отдельные точки и по 1 кассе. и все обязано быть автономно, не зависеть от сети внутри.
Правила типовые менять - нет понимания для чего объекты в базе нужны или понадобятся при обновлении. марки и ШК упаковок должны быть. по их статусам продажи.
Как они ходят знаю, но это не связано с блокировкой же..
не всегда - много справок и ШК ходят т.к. товар бродит по перемещению.