РИБ ошибки при обмене dbeng #787052

Есть база УТ 10.3 10.3.19.4 (файловая, пиленная), около 7гб, и несколько розничных точек, РИБ FTP. Последнее время стала периодически (3-4 раза в месяц) вылетать ошибка "Ошибка СУБД. Внутренняя ошибка компоненты DBENG8" на розничных точках, помогает chdbfl.exe + ТИИ, но не на долго. Пару лет назад пробовал настроить автообмен через рег задания, но такие глюки появлялись через день запуска, поэтому используется ручной запуск обмена, пару раз в день. Обновил платформу в надежде что это глюк платформы, не помогло. Перерыл интернет, но что то ничего вразумительного не нашел. Есть у кого нибудь соображения на этот счет?

помогает chdbfl.exe + ТИИ, какие исправления пишет. Может в это сторону нужно глянуть

база 7 Гб не пугает что файловая?

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

Помогает, но не на долго. chdbfl.exe либо вообще без ошибок, либо таблица files повреждена. ТИИ каждый раз разные ошибки выводит. Особо не пугает, встречал базы и поболее. А если предложить клиенту перевести все точки на SQL, он меня не поймет. Есть еще у кого нибудь, какие нибудь предложения?

Ssd предлагали?

нет, не предлагали, думаешь что то изменится?

вообще я думаю да

Во время работы обмена в базе сидят пользователи?

Да, бывает что сидят.

Спасибо, подумаю над этим предложением.

Есть возможность делать технические перерывы, чтобы на момент об обновления никто не работал?

ссд в этой ситуации вообще ниочем

а откуда уверенность, что причина ошибок в обмене РИБ? Может быть там в принципе Розница "умирать" будет даже при выключенном РИБ

Розница-то, может быть, и мрёт, а вот УТ 10, если она запускается только локально - не должна. Хотя, если у кого-то руки до креста охочи особенно при записи, то тут файловая действительно не при делах, но - проще обновить пользователей, чем покупать SQL, последний ой как не любит, чтобы компьютер выключали.

Ну можно конечно все обязать закрыть 1С, но я не понимаю как у людей обмены работают в реальном времени. тоже думаю что особо не поможет. ошибки возникают в процессе обмена (загрузка/выгрузка), особенно это было заметно когда был настроен обмен рег. заданием. вот вероятность того что пользователи прибивают базу во время обмена есть. Вопрос к тем у кого обмены работают в реальном времени, нет ли у Вас таких глюков?

просто операция с загрузкой данных оказалась наиболее чувствительной к появлению ошибок. Я со своей стороны могу уверенно судить, что ошибок никогда не было в тех обменах, что я сам разрабатывал и не использовал выгрузку/загрузку данных из регистров. При установке в выгрузку данных регистров и с использованием ведущих отборов и регистраторов (т.е. регистры накопления с остатками и оборотами (разные сочетания)) наступать на грабли с созданием ошибочных данных пришлось. Но! все объекты, которые шли в обмене, обязательно содержали предопределенную ПередЗаписью и ПриЗаписи с проверкой на возврат без обработки данных в случае ОбменДанными.Загрузка.  Это позволяет всегда завершить обмен без выдачи ошибок, но! ошибки сразу там были и их появление пришлось предотвращать. Из-за ошибок база падала именно в файловом режиме. Так что по написанному хотел сказать, что проверить можно содержание обмена, состав объектов в обмене, обработку объектов при получении данных и т.д. Только при этом не надо забывать, что и без обмена можно заставить базу работать через пень колоду.

У нас на РИБе периодически та же проблема выскакивает.

Это у Вас типовые обмены РИБ или же самописные по правилам? Друг по несчастью! Как боретесь?

Так же, как и вы ))) chkdbfl и ТИИ))) Но у нас и посерьезней проблемы есть. Например, повреждение 1cd при закрытии смены - то еще удовольствие.

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

Ап. Либо ни у кого нет РИБа, либо у всех он работает без проблем. Ау... гуру по рибу.

вангую...3-4 месяца назад сделали бекапы архивированием файла базы. файл обрабатывается когда в нем сидят пользователи.

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

Раздача данных идет из центра в точки. Падает база на точках. Синхронно на всех, после какого-то конкретного пакета? Что за данные раздаются в точки, если у одной точки, допустим, были продажи и после загрузки этих продаж в центр документы и данные об этой продаже разъедутся во все точки и в сам первичный источник? А если это не так, значит в обмен вносились изменения и довольно существенные на предотвращение избыточной регистрации объектов и предотвращение избыточной выгрузки данных в точки. При этом могли быть допущены ошибки в написании кода и часть данных в точки идет испорченной, т.к. что из нужного обрезано.

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

это ошибка не из за риба.

Почему при загрузке XML файла падает (dbeng) программа, даже если в файле есть битые ссылки они ведь загрузятся. Я не думаю что тут проблема с файлами обмена. На мой взгляд проблема в базе, либо в движке. Вот я и спрашиваю, что люди делают с проблемными рибами (кроме проверки базы). И как у людей работает риб с обменами каждые 5 минут!? Я пробовал три раза делать периодический обмен, и в этих трех случаях у меня начинали вылазить ошибки dbeng практически в первые несколько дней работы. Уже есть желание забить на риб и ставить что то типа фронтола.

Версию платформы сменить

да е... мое. А я тебе что писал выше?! Проблема не из-за РИБ и сомнение это озвучил еще в 13 посте Но тебе почему-то хочется потрепать тему РИБ. Давай дальше ее трепать. РИБ тема обширная для трепа, даже очень обширная.

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

И при загрузке из РИБ (в момент получения данных от Главного) программа падать не должна, если у тебя в нем все сделано правильно.

// Уже есть желание забить на риб и ставить что то типа фронтола. Так в этом вся и проблема, что Фронтол кто-то продавливает, как универсальное решение? Но это же чисто кассовое ПО. Наличие Фронтола на кассе никак не отменяет и не заменяет наличие УТ в Центре и точке. Из центра в точку идет выгрузка по УТ, а на ККМ идет другая выгрузка внутри точки из УТ базы на саму ККМ.

а это все рассуждение дает повод сделать вывод, что РИБ в данном примере не совсем РИБ. Переделанный он. И весьма существенно должен быть переделан.

Обновил до 8.3.8, тоже надеялся что будет все ок, но толку нет, последний раз на ней глюк и произошел. отладку загружаемого пакета не делал, да согласен нужно сделать в следующий раз. Риб в двух местах был не изменен (штатный), в одном добавлен обмен чеками, больше ничего не менял. Раз проблема периодически возникает во время обмена риба как ты думаешь что я должен думать, риб глючит или нет? В данном конкретном случае фронтол подходит без доп. ут на точке, просто руководитель захотел, чтобы все было сразу в одной программе. А если нужно всех выгонять чтобы обмен правильно работал без глюков, то как у людей работает обмен каждые 5 минут?

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

Спасибо за информацию к размышлению! Буду ждать очередного глюка и отлаживать загрузку.

периодически выскакивает такая хрень, тогда когда неправильно закрыта 1С, реиндексация помогает, но через некоторое время приходится делать chkdbfl с исправлениями ошибок