РИБ - блокировка при обмене #570245

Добрый день! Существует такая проблема: стоит розница РИБ - обмен настроен каждый час(выгрузка и загрузка с обоих сторон). Обмен настроен по расписанию. Суть проблемы в том, что бывают такие моменты когда идет пробитие чека и стартует обмен(загрузка данных) - тут таки происходит ошибка пробития чека(т.е обмен все блокирует), самое страшное и серьезное в этой ситуации, то что стали пропадать чеки время от времени(бесследно),т.е обмен включился во время записи чека в базу, произошла блокировка и чек не куда не сохранился. Может кто то уже сталкивался с такой проблемой. Или есть какие мысли по этому поводу, как лучше сделать, чтобы избежать такой ситуации?!

Я не сталкивался, но мне кажется, что если положить под SQL то проблему можно решить раз и навсегда, обойдясь без 1С-ного обмена, делая обмен средствами SQL.

Средствами 1С - выставлять флаги "идет обмен" и "идет проведение чека". После выполнения заданий - сбрасывать. Перед началом обработки проверять. И не выполнять до сбрасывания флага. В качестве флага можно пользовать константу.

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

База кладется под СУБД и представляет собой не один файл *.1CD, а множество сравнительно небольших файлов, организованных в таблицы. Записью, чтением и блокировками управляет СУБД. Приложение 1с "общается" с СУБД через программный продукт "1С сервер"... Имея под СУБД две базы и задачу синхронизации данных между ними, можно средствами СУБД организовать миграцию данных. При этом данные из одной базы в другую будут попадать в течении нескольких секунд.

Описал сильно упращенно, но по сути верно.

не стоило так прям расжовывать=) Но спасибо за старание. Просто вопрос в том,что они обе должны быть SQL?! Одна из этих баз SQL - главный узел. Но обмен настроен с помощью файлов, которые заливаются на FTP.

Потому что подчиненная файловая. Поэтому обмен через файлы и FTP. Да, обе должны быть SQL.

Может быть, при открытом чеке нужно тормознуть обработчик ожидания, который следит за вашим расписанием? А при закрытии чека снова включать. В КА он называется "ПоддержкаРегламентныхЗаданийДляФайловойВерсии", в рознице не знаю. Недостаток в том, что в этом случае остановятся все регламентные задания, пока не закрыт чек.

вот это больше мне нравится. Попробую что нить типо этого сделать!!! Идейка не плохая!!!

Убрать вообще чеки из обмена, и база расти не будет и тормозить меньше будет.

не поможет

+Если очень надо чеки, сделать выгрузку их после закрытия смены.

нужны. сейчас в рознице много отчетов которые костароены именно на чеках!

Делайте тогда выгрузку только со статусом "Архивный"

т.е. в 1с идет перегрузка не сохраненных новых документов?? и изза этого блочится вся перегрузка? =)

Не особо поняла, смысл выгрузки/не выгрузки чеков в центральный узел?!

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

Если очень надо их то больше всего подходит. Тупить тогда оба будете и кассир и обмен.

Нужно сделать чтобы приоритет был у чеков. Пусть при блокировках вылетат обмен а не чек.

2 рассказывай как.

Можно уменьшить параметры в ПланыОбмена.ЗаписатьИзменения(,) ПланыОбмена.ПрочитатьИзменения(,) Посмотреть нет ли где НачатьТранзакцию ЗакончитьТранзакцию Нет ли во время обмена тяжелых запросов.

а что собственно блокируется при обмене то?

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

Мысль конечно гениальная, первое что приходит в голову. А второе, что приходит - это как это сделать?! не происходит запись или пробитие чека на фискальном регистраторе! да да да!!!

А вы чем торгуете (продукты, одежда и т.д.) ?

1С это не даст сделать. Более того на таблицу изменений нельзя даже наложить блокировку. Т.е. выгружается и блокируется вся таблица

белье!

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

А для чего такой частый обмен? Может сделать 2 обмена? Каждый час загрузка прихода и справочника, и вечером выгрузка документов

И как он поможет, если обмен уже начался?

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

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

Ну так приход не будет блокировать расход (разные таблицы)

Между началом обмена и блокировкой есть достаточно времени чтобы пробить чек (пока скачает с FTP, потом загрузка, только потом, при выгрузки, блокировка). Так что проще при записи проверять "идет обмен, подождите"

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

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

Так это уже встроено в 1с, привязать к кнопке в РМК и вручную делать обмен

Константа?

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

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

нет конечно. Раз в час, по расписанию!

Создать второго пользователя "Автообмен" не предлагать ?

т.е. открыто две адинэски, под кассиром и под автообменом, кассир продает, автообмен раз в час ведет обмен с ЦУ.

А поможет? помоему нет...все равно блокировки будут..делайте обмен вручную..когда чеки не бьете.

С нормально будет, главное мешать не будет.

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

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

+"Еще вариант - отключить авторегистрацию" - имеется в виду авторегистрацию в плане обмена для чека, остальное не трогать...

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

Авторегистрация и так отключена

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

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

регистры накопления и прочие регистры они как бы отдельно грузятся. Я понял что у лочится таблица документа а не регистры...

Ща код дам

а вообще как то странно что при обменен лочится вся таблица доков...

лочится таблица изменений плана обмена. попробовать через КД делать обмен?

После закрытия смены делаем обмен и выгружаются все чеки за закрытую смену.        ИЛИ НЕ ПараметрыСеанса.НаличиеОбменаДаннымиПоКассе Тогда

1C  с кассы убери и будет тебе счастье.

"лочится таблица изменений плана обмена." нет такой таблицы. Изменения хранятся в таблице документа, не?

Самое правильное и верное решение !!!

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

и что у тебя все 20 узлов в одну базу льются? че иерархию не делала?

а соврал - изменения хранятся в отдельной таблице для каждого дока эта таблица своя...

есть ЦУ в который сливается все с 20 узлов, а по узлам идут только их данные!

ну для иерархии это не отмаз, однако насчет участить интервал до, например, раз в 5 минут я бы подумал, хотя тут надо смотреть скорость загрузки изменений в ЦУ из сообщения обмна...

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

и кстати насчет пропадания чеков - ты иэти пропавшие цеки в центральной базе искала? А то мож добрая душа в ЦУ поменяла, например, организацию, и тю-тю - в одной периферийке чек пропал, в другой - "воскрес"

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

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

ага, согласен. но это отдельные физические таблицы под это дело.

искала, все перерывали. Просто пропадают и всё.

т.е. появляются "Объект не найден"?

ктото стащил по уиду и сделал как новый документ, может быть такое?

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

т.е вообще не следа, не битыйх сслылок ничего!

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

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

ну так если он пропал в источнике и приемнике какая накладка?

Предположений не нужно. До момента азаписи объекта в базе не существует. Транзакция записи из-за наложенных обменом блокировок отменяется. Ваша программа такую ситуацию не обрабатывает. И повторных попыток записи не делает. Соответственно чека в базе нет.

думаю так и получается.

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

Ну так положите вызов проведения чека внутрь попытка -исключение - КонецПопытки. И если ошибка из-за блокировки повторите запись(проведение).

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

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

А вроде же таблица регистрации лочится не на все время обмена а на время обработки текущего объекта. Один объект записывается доли секунды, чек должен успеть вклиниться и заблокировать уже таблицу регистрации. ПрочитатьИзменения(<Чтение сообщения обмена>, <Элементов в транзакции>) " Но при чтении сообщения в многопользовательском режиме могут быть конфликты блокировок между транзакцией, читающей данные из сообщения и помещающей их в базу данных, и транзакциями, выполняемыми другими пользователями. Кроме того транзакции, в которых модифицируется слишком большой объем данных могут работать медленно или вовсе завершаться аварийно. Особенно в файловом варианте базы данных. Для того, чтобы избежать таких неприятностей можно задать значение этого параметра, отличное от значения по умолчанию. Чем меньше значение параметра, тем меньше вероятность конфликта блокировок, но выше вероятность помещения в базу данных несогласованных данных. Значение по умолчанию: 0 "

ну то есть можно настроить чтобы лочилось не на весь обмен а на объект

То есть можно настроить так

штатный механизм обмена работает сам по себе и там все элементы в транзакции

По любому вся таблица будет лочится