Внимание! Обнаружен подводный камень величиной с хорошую скалу в организации обмена в распределенной базе 1С:Предприятие 8. Если у вас клиент-серверный вариант базы, и обмен между узлами выполняется по расписанию, то вы можете налететь на этот камень на полном ходу. Дело в том, что, создавая копию базы (например, для отладки) в клиент-серверном варианте, мало кто заботится о том, чтобы регламентные задания в копии базы были выключены. Если их принудительно не заблокировать, то получится следующее: ваша копия будет делать обмены по тому же расписанию, что и основная база. К чему это приводит, нетрудно догадаться — пакеты обмена будут «теряться», то есть попадать не по назначению. И объекты, которые в этот день должны были попасть в основную базу, попадут в копию базы.
Чтобы устранить последствия, нужно следующее: моя обработка, (не)много терпения, навыки работы с журналом регистрации.
Порядок работы с обработкой:
1) Скачиваем обработку
2) Заходим в 1С на ДРУГИХ УЗЛАХ БАЗЫ (если копия базы стоит в центральном узле — на всех периферийных), открываем журнал регистрации, вычисляем тот период, когда с обменом был косяк (к примеру, мы знаем, что копию базы поставили 13.07, а спохватились только 20.07, и обмен идет раз в сутки, ночью, тогда нужно поставить период с 12.07 по 20.07), далее через меню «Файл»-«Сохранить как» сохраняем в файл журнал регистрации. Он нам понадобиться в обработке.
3) Стандартными средствами делаем обмен в распределенной базе.
4) Открываем обработку. Подставляем вычисленный период, задаем файл, в который сохранили кусок журнала регистрации, выбираем узел, С КОТОРЫМ выполняется обмен (в нашем примере — центральный узел).
5) Нажимаем на кнопку «Выполнить» и ждем. В процессе обработка зарегистрирует для выбранного узла плана обмена все объекты, которые были изменены (добавлены, проведены и т.д. и т.п.) в заданный период, исходя из данных журнала регистрации.
6) Снова выполняем обмен. Теперь в обмен попадут и все объекты, которые были пропущены из-за косяка.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Это не косяк… Это так себе, недочет, который элементарно исправляется условием Если этотузелглавный и т.д.
А вот ОГРОМНАЯ лажа, с которой столкнулся недавно, это ВРЕМЯ…
Ух как я долго доходил до этого 🙂
Ситуация следующая — запрещены проведения задним и передним числом и отрицательные остатки. Но какого то … все равно они вылазили.
База стоит распределенная по 20 городам и с правилами для каждого города.
И вот вот ситуация — в основной базе строят отчет и видят отрицательные остатки… У всех паника, программиста пинают 🙂
Пример(очень грубый) у меня стоит дата на основной базе 10.01, и я делаю перемещение товаров на магазин. У магазина стоит 5.01 и он МОЖЕТ продать, так как в 1С стоит проверка по обороту за все время, а не на конкретную дату документа. И теперь он нам присылает обмен, мы формируем например за 7 число, и видим отрицательные остатки 🙂
Короче, долго лазил в 1С, так и не смог изменить их механизм, так как во многом он себя оправдывал.
Выход нашел только один — сделал при запуске системы проверку на наличие в регистре «товары на …» на дату, и если дата компьютера меньше, то просто блокирую все панели, пока не изменят дату…
Если кто сталкивался и знает более гумманое решение прошу отправить меня к нему по линку или отписать…
Много букв, но для тех кто ранее не сталкивался с распределенными базами, это сэкономит много времени (ну или я такой тугой:)
а с какого будуна если сейчас 10.01, в магазине стоит 5.01…???
скриншоты?
(2) а вот у них биос сбивается(батарейка села) и у них вечно 01.01.2004 🙂
короче таких всего 1%, но то что они есть, говорит о том, что блин даже за временем надо следить ….
Надо включить их в домен или при запуске делать комманду net time.
Мега косяк в урбд другой.
у меня распределенка типа дерево. У центра 2 узла у одного из узлов есть еще 1ин подчиненый узел. Так вот. Если сделать при такой схеме динамическое обновление во-первых центральная база у разных пользователей прекращает операции по блокировкам. И есть 30- 60% вероятность что один из узлов отвяжется. При обмене будет писать ошибку — что конфигурации центра и переферии неодинаковые. Вот это реальный косяк.
#5 Ну как бы а что Вы хотели. Динамическое объединение зло. Даже официальные лица 1С на всех форумах и встречях говорят не юзать динамическое обновление 🙂 а тем более если у Вас УРБД и не линейной структуры.
(6) можно ссылку хотя бы на одно такое сообщение от сотрудника 1С?
(0) лучше последствия предугадывать чем исправлять.
просто помести подобные строки в начало процедур регламентных заданий:
Если нрег(АЛН_ПолныеПрава.ПолучитьСтрокуСоединенияИнформационнойБазы()) <> нрег(АЛН_Инструментарий.СлужебныеКонстанты_Получить(«АЛН_ОбменДанными.СтрокаСоединенияИнформационнойБазы»)) тогда
ВызватьИсключение(«Расположение информационной базы изменилось.»);
КонецЕсли;
тогда при создании копии, никакой обмен сам не запустится
Rebelx дело говорит. 1с-цы овцы недобитые. Во многом по обменам дебилизмус за эталон продают. Защиты никакой не предусмотрели и ни в одном описалове нет упоминаний.
(0) Согласен с Reblex (8), поскольку забыть отключить фоновые задания может каждый.
А так обработка полезная (если уже прозевал фоновые обмены, то надо ведь исправлять 🙂
Вопросы очень актуальные по поводу обменов. Например именно такая ситуация была и у меня, очень долго разбирался.