Действие недоступно для этого узла 1с
Всем привет! Подскажите пожалуйста, кто силен в планах обмена, как удалить планы обмена в базе, которая уже не является участником обмена. Надо из базы со множеством юрлиц, выгрузить одно юрлицо. Идея возникла выгрузить через план обмена. Все выгрузилось хорошо. Потом я отвязал новую базу от основной, чтобы уже новую выгрузку сделать основной базу для одного юрлица. Ну и решил удалить из плана обмена не нужный план обмена. При удалении получаю "действие недоступно для выбранного узла". Узел не основной, удалить не могу, а хотелось бы, чтобы не видно было, что база получена через РИБ. Изначально идея была такая: выгру
А нах так сложно - не проще было в копии базы всё выпилить как надо?
мне кажется такой способ более трудоемкий, как выпиливать справочники? Много лишней информации останется. Надо писать обработку для анализа нужен тот или иной элемент справочника или нет. Можно еще через конвертацию данных сделать, установив фильтры по организации, но тоже надо правила писать. Самым быстрым получилось с помощью правил обмена, но есть пару моментов, о которых я и спрашиваю))
Открой пустую базу через CF и перенеси туда универсальной обработкой из полученной базы. Но ИМХО - это лишнее. Никому не интересно знать как ты эту базы получил.
я пробовал так делать, вариант не айс. Один адресный классифмкатор выгружается три часа, причем диск ссд.
в данном случае интересно. Задача такая, чтобы база была по юрлицу, как будто он ее сам вел все время. Даты документов, движения по документам, периоды в регистрах.
Перед выгрузкой вычисти адресный классификатор. Его можно и потом выгрузить. Но если вернуться к исходной базе, то посмотри, на что ссылается удаляемый объект. Может быть, есть справочник или регистр с настройками, которые не нужны
ну я к тому что и даные тоже долго выгружаются. да может кто то копнуть))) задача есть, я делаю. Тут такое дало, что ошибка эта в системном окне платформы появляется. План обмена, это вроде справочник, а я даже пометить на удаление не могу. То есть даже до проверки ссылок не доходит.
План обмена - это не справочник. Я говорил про ссылку на узел обмена.
А узел обмена можно переименовать интерактивно или программно.
Групповой обработиной с Инфостарта пометить на удаление и удалить.
в конфигураторе у меня есть план обмена ПоОрганизации В пользовательском режиме в Операции-ПланыОбмена(ПоОрганизации) есть основной и дополнительный план обмена. Хочется удалить дополнительный план обмена. скорее всего не удалит, я с кода удалял то же предупреждение. "действие недоступно для выбранного узла"
нельзя удалить узел, который соотносится с текущей датой.
я понял что ты имеешь ввиду, я такое делал, ссылок нет. Тока это у меня Операции - Поиск ссылок на объект, не новая база)) а это можно подробней? как сделать чтоб не соотносилась тогда с текущей датой?
В старых конфигурациях, на не управляемых формах ЗУП 2.5 и Бух 1.XX нет кнопки "Все функции", там есть в меню "Операции". Это я не понял "нельзя удалить узел, который соотносится с текущей датой." С какой датой? Как он соотносится?
Конечно удалил. ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
Очепятка)) Извини. *соотносится с текущей конфигурацией (базой)
Нет проблем)) Получается основной узел и который соотносится с этой базой будет всегда присутствовать и не удалишь его? А это может где то на ИТС написано? Откуда такая инфа? Неужели он на уровне платформы проверяет?
Полечил зубы через одно место, но мне кажется криво получилось. Взял в конфигурации грохнул план обмена "ПоОрганизации". Потом взял cf с эталонной конфигурации и загрузил его в новую базу, где надо было удалить дополнительный план обмена. Все стало нормально, только вот нормально это или нет не знаю. Не всплывет ли это где либо в будущем??
Полагаю, в документации есть и на сайте ИТС и на просторах инета. Открой пустую базу и там уже есть узел. Это нормально. Не всплывёт. Главное проверь, чтобы не было физ лиц, сотрудников и контрагентов, которых не должно быть в этой базе.
ну да, это я проверю еще. Будем надеяться что все будет нормально))
Сотрудников точно не будет, потому что они к организации привязаны. А вот контрагентов и физлиц надо выцеплять, тех на которых нет ссылок.
Это потому что есть какая то информация ? Или так просто чтоб потролить?))
Рассмотрим случай, когда данные во всех узлах синхронизируются полностью. Это идеальный случай - для исходных данных (данных восстановления) можно использовать любой узел РИБ. В случае, когда обмен происходит по собственным правилам или, например, установлен фильтр по организациям, то для исходных данных (данных восстановления) необходимо выбирать узел с наиболее полными данными.
. ВАЖНО. Перед созданием БД необходимо выполнить полную синхронизацию всех узлов РИБ с узлом, из которого планируется создавать новую БД, и на время создания в этом узле отключить синхронизацию данных!
Все действия выполняются в монопольном режиме (т.е. у целевой БД должны отсутствовать активные соединения).
В качестве "исходного узла" выберем "Корневой узел" (см. схему РИБ). В нем аккумулируются данные всех узлов.
ВАЖНО. В качестве "исходного узла" рекомендуется выбирать узел, который впоследствии станет главным узлом для вновь созданного/восстановленного узла.
Это не обязательное условие. Для восстановления РИБ подойдет любой узел с максимально актуальными данными.
0. В режиме предприятия создаем новый узел РИБ в "исходном узле".
Данное действие необходимо, если создается новый узел, в противном случае необходимо перейти к п. 1.
1. Выгружаем базу данных из "исходного узла" в файл (*.dt).
Для "пухлых" БД можно просто скопировать 1Cv8.1CD, для клиент-серверных БД - например, скопировать средствами СУБД.
2. Загружаем полученную в п. 1 выгрузку в "чистую" БД.
3. Запускаем полученную в п. 2 БД в режиме предприятия и отключаем все настроенные синхронизации данных.
4. Отключаем автоматическое обновление предопределенных данных в подчиненной БД.
Это необходимо потому, что в главном узле предопределенные данные обновляется автоматически, а в подчиненные узлы уже "приезжают" с обменами.
Если не выполнить это действие, то после отключения главного узла при следующей реструктуризации БД произойдет задвоение предопределенных данных.
Для отключения необходимо запустить командную строку от имени Администратора (root`a), выполнить запуск конфигуратора с параметрами и дождаться выполнения (сам конфигуратор на экране не появится, но он будет отображаться в дереве процессов системы, т.е. необходимо дождаться когда процесс конфигуратора пропадет из дерева процессов):
для Linux-клиента "файловый" вариант БД:
для Linux-клиента "клиент-серверный" вариант БД:
для Windows-клиента "файловый" вариант БД:
для Windows-клиента "клиент-серверный" вариант БД:
соответственно подставить свои путь к исполнительному файлу 1cv8 или 1cv8.exe и переменные, где:
УТ11.2.3.175 Предприятие 8.3.8.1784, РИБ полный обмен. В одном из подчинённых узлов повреждён файл 1cv8.1cd. ТИС не помогло. Благо данные мигрировали в главный узел, надеюсь здесь потерь нет. Решил пересоздать подчинённый узел. Создаю из главного начальный образ. Открываю его как новую базу. Запрашиваются параметры синхронизации, по умолчанию выставленные, как у последнего созданного до этого образа. Выставляю нужные, всё успешно завершено. Захожу в новом подчинённом в пункт "синхронизация" - список узлов пуст. Доступен только "Настроить синхронизацию данных" (для создания новых). Ладно, пытаюсь создать через него новый РИБ, указывая в качестве префикса базы партнёра префикс главного узла. Не даёт - "синхронизация с таким префиксом уже существует". Что за чорт?
Так узел новый создал или старый повторно выгрузил?
(4) Пытался выгрузить старый. Т.е. в главной базе открыл настройки синхронизации с убитым узлом и нажал "создать начальный образ". Когда этот образ открыл, там по умолчанию префикс и настройки другого подчинённого узла были, не того что нужен, а того который создавался перед этим. Я их руками правил.
(5) MGMGA, Что то не то у тебя с узлами. Тестирование ЦБ делал? Чеком и ТиИ?
(8) Да, специально сделал, чтоб убедиться, что файл не повреждён как в подчинённом узле.
(7) MGMGA, очистку кэша делал? Не знаю насколько это может помочь, но может быть в каком-то временном файле сохранились настройки и теперь не дает создать тоже самое еще раз!
(14) MGMGA, есть скрипт специальный, поищи в интернете (Очистка кэша 1С), он в свободном доступе. Ну и в папке с базой все файлы поудалять нужно. Но это наверно не поможет, я следующем постом написал.
(2) Так не интересно. Желательно префиксы баз сохранить.
Наверное придётся удалить в главной базе связь с узлом, после чего попробовать создать новый с префиксом старого.
Наверное придётся удалить в главной базе связь с узлом, после чего попробовать создать новый с префиксом старого.
Пробуйте удаляйте тогда узел из плана обмена и создавайте новый.
(11) TODD22, так ты получается не удалял старый? Я думал при создании нового программа ругается. Тогда конечно лучше удалить и попробовать создать заново, должно всё получиться
Попробовал создать абсолютно новый узел. Всё создалось, настроилось успешно, но в новой базе список планов обмена так же пуст. Доступно только "настроить синхронизацию данных", но префикс главной базы не пропускает.
Вроде разобрался. План обмена Центральной базы оказался помеченным к удалению. Непонятно, как оказался помеченным и как происходили обмены. Похоже случилось автоматически при обновлении.
Что характерно, в каждом узле сам этот узел оказывается помеченным к удалению. Через синхронизацию пометка на удаление не передаётся. Так же помеченны к удалению пустые синхронизации с бухией и розницей, но удалить весь этот зоопарк невозможно - "действие недоступно для данного узла".
Пометка на удаление узлов РИБ ставится при тестировании и исправлении соответствующей базы.
Пометка на удаление узлов РИБ ставится при тестировании и исправлении соответствующей базы.
(20) Я полагаю такое происходит после прехода на 11.2 Видимо план обмена связанный с самой базой больше не используется, и по логике вроде не нужен. Только при создании нового узла глючит, видимо не учли.
(21) MGMGA, И как без плана обмен работает? На EnterprisData перевели?
(22) Так EnterpriseData вроде для синхронизации с другими прогами, РИБ УТ разве можно?
План я не удалял на всякий случай, снял только пометку на удаления. Судя по тому, что с пометкой работал, наверное и после удаления должен работать нормально.
Читал в описании одной из конф что будет переход обмена РИБ на ED. Но он так и не состоялся. видимо.
Почему нет? В принципе по ED передаётся только учётная информация. А метаданные для обновлений через РИБ.
Хотя и ED должен работать на планах обмена вроде как.
Может там просто глюк платформы? Читал в соседней ветке что выходили 2 глючных релиза. на которых были проблемы с РИБ.
"Возникла проблема при настройке передачи данных из конфигурации Управление Торговлей редакция 11.0.7.8 в конфигурацию Бухгалтерия предприятия редакции 2.0.28.3.<br> <br>Режим работы файловый, настройка обмена - через каталог.<br> <br>Префикс управления торговлей ЦБ, префикс бухгалтерии - БП<br> <br>Было сделано несколько попыток создания обмена.<br> <br>При начале настройки обмена на стороне УТ, создается файл с настройками, при продолжении настройки обмена на стороне БП, при загрузке файла с настройками программа выдает ошибку - «В этой информационной базе уже настроен обмен. Удалите предыдущую настройку обмена». Единственная настройка обмена, которую я вижу и к которой судя по коду обращается Обработка ПомощникСозданияОбменаДанными, эта предопределенная в конфигурации настройка - Настройка обмена данными с «Управление торговлей, редакция 11.0», с кодом 000. Понятно, что с этой настройкой я ничего сделать не могу<br> <br>Пытался удалить ее программно -<br>Написал внешнюю обработку, с одной кнопочкой. <br>Ниже код обработчика кнопки<br><pre>==========начало==========Процедура КнопкаВыполнитьНажатие(Кнопка) // Вставить содержимое обработчика. ПеременнаяНаша = ПланыОбмена.ОбменУправлениеТорговлейБухгалтерияПредприятия.НайтиПоКоду("000"); Сообщить(ТипЗнч(ПеременнаяНаша)); УдаляемыйЭлемент = ПеременнаяНаша.ПолучитьОбъект(); Сообщить("Прошли контрольную точку"); Сообщить(ТипЗнч(УдаляемыйЭлемент)); УдаляемыйЭлемент.Удалить(); КонецПроцедуры=============конец кода=================</pre><br><br>Обработка отрабатывает с ошибкой -<br><pre>Ошибка при вызове метода контекста (Удалить) УдаляемыйЭлемент.Удалить(); по причине:</pre><br><br><br>по причине: <br>Действие недоступно для этого узла <br><br>Точно такю же ошибку мне сообшала программа при попытке в режиме Предприятия удалить этот узел. <br><br>Есть мысли куда копать?<br> <br>Похоже, что в программе где-то осталась некая информация о прошлых попытках настройки - в регистрах сведений, в справочниках, в константах. Укажите пожалуйста где искать проблему."
Повышение надёжности 1С:Предприятия это одна из задач, которым мы уделяем постоянное внимание. Значительную роль здесь играет защищённость кластера от сбоев, которые могут произойти как аппаратных, так и в программных компонентах кластера. Для решения этих проблем в кластере существуют несколько направлений резервирования и механизм автоматического распределения нагрузки. При обнаружении сбоя этот механизм самостоятельно переведёт работу на резервные компоненты.
Однако прежняя архитектура кластера обладала таким недостатком, что возникновение сбоя не во всех ситуациях диагностировалось достаточно быстро. Например, при неисправности сети, при разрыве соединения между процессами кластера, могло пройти довольно длительное время до того, как механизмы отказоустойчивости и распределения нагрузки обнаруживали проблему. В результате функциональная нагрузка с недоступного узла кластера «перебрасывалась» неоперативно, со значительной задержкой.
Для того чтобы сократить время реакции кластера на разрыв соединения мы реализовали механизм отслеживания целостности сетевых соединений. Этот механизм отслеживает внутренние соединения между процессами кластера, и внешние соединения между кластером и расширениями веб-серверов.
Использование этого механизма позволяет, во-первых, оперативно обнаруживать разрывы связи между процессами, а во-вторых, снижает общие накладные расходы на отслеживание целостности соединений.
Проверка соединений осуществляется сразу для группы соединений, называемой направлением. Существуют правила, по которым платформа автоматически группирует несколько соединений в одно направление. Для каждого направления происходит периодическая отправка небольшого проверочного пакета данных, и ожидание ответа на него. Проверка осуществляется как на стороне источника этих соединений, так и на стороне приёмника.
Для отправки и приёма проверочных пакетов используются последовательно два протокола: UDP и TCP.
По этой причине при установке кластера и при публикации информационных баз на веб-сервере мы рекомендуем теперь обеспечить взаимную доступность между компонентами не только по TCP, но и по UDP с теми же номерами портов. Под компонентами в данном случае понимаются рабочие серверы кластера и компьютеры веб-серверов.
Алгоритм проверки выглядит следующим образом.
Пакеты отправляются по протоколу UDP. До наступления таймаута ожидается ответ. Если ответ получен, направление считается доступным, и проверка по протоколу UDP продолжается. Если в какой-то момент ответные пакеты UDP перестают приходить, направление считается недоступным.
Отдельно обрабатывается ситуация, когда за все время жизни направления не получено ни одного ответного пакета по протоколу UDP. В этом случае направление продолжает считаться доступным, но для дальнейшей его проверки будет использоваться протокол TCP. Устанавливается TCP соединение, и проверка идет через это новое соединение по тому же принципу. Если до наступления таймаута не пришло ни одного пакета от противоположной стороны по протоколу TCP, направление считается недоступным.
После того, как направление признано недоступным, все соединения этого направления помечаются как непригодные для использования, и будут разорваны при следующем обращении к ним. Кроме этого механизмы кластера оповещаются о разрыве соединений для оперативной реакции на это событие. В том числе для удаления блокировок, соответствующих недоступному процессу.
Механизм имеет два настраиваемых параметра:
- Период проверки — период отправки пакетов в миллисекундах. Стандартное значение: 1000.
- Таймаут проверки — время, в течение которого ожидается хотя бы один ответный пакет, чтобы данное направление соединения считалось доступным. Стандартное значение: 5000.
Стандартные значения выбраны так, чтобы с большим запасом исключить ложные срабатывания при штатной загрузке сети и другого оборудования. В то же время эти значения обеспечивают комфортное время реакции на аварии на сетевом оборудовании, или на узлах кластера.
Мы предоставляем администраторам кластеров возможность отслеживать качество соединений между серверами и самостоятельно настраивать механизм. Для этого можно использовать технологический журнал. Раз в 10 секунд в него пишется статистика проверки. В частности, выводится информация о среднем времени ответа, и о максимальном времени ответа. На основании этой информации администратор может выставить минимальные таймауты, которые, не будут приводить к ложным срабатываниям системы проверки.
Примерный сценарий настройки может выглядеть следующим образом:
- Администратору приходят жалобы пользователей на то, что у них разрываются соединения. Или же происходит перезапуск процессов.
- В технологическом журнале администратор обнаруживает, что срабатывает система отслеживания разрыва соединений. Например, из-за перегрузки сети или узла кластера. Кроме этого администратор видит, что среднее время ответа велико, и приближается ко времени таймаута. А максимальное время ответа часто превышает его.
- Наилучшее решение в этой ситуации - масштабировать оборудование. Но если такой возможности нет, то администратор может увеличить время таймаута, чтобы система не сбрасывала соединения. Тем самым смирившись с общей перегрузкой системы.
Для соединений внутри кластера значения периода проверки и таймаута вы можете задать с помощью параметров командной строки pingPeriod, и pingTimeout. Эти параметры можно использовать при запуске агента сервера как службы, «демона», или как приложения.
Читайте также: