Быстрое создание начального образа подчиненного узла #689685

Доброго времени суток, комрады. с распределенкой я больше на вы, нежели на ты, поэтому есть пара вопросов. суть такая. нетиповая УТ 11 (клиент-сервер), есть план обмена со своими правилами, параметрами(отбор по организации, складу, подразделению и прочее) и узлами. вопрос первый: при создании образа подчиненного узла эти отборы учитываются? а то поставил на создание и висит уже это добро относительно долго (2-е суток). база порядка 50 гигов. знаю, что есть метод быстрого создания образа путем определенных махинаций со снятием признака главного узла и т.д. но в данном случае в такой базе будут все документы, движения и прочее, которые филиалу ни к чему. удаление этих доков займет фиг знает сколько времени. соответственно плавно походим ко второму вопросу: если на самом скуле почистить таблицы документов, регистров накопления и другой ненужной информации - каким боком это может вылезти в дальнейшем? возможна ли ситуация, что id документа, который пришел к примеру из другого узла, совпадет с id документа из узла созданного таким образом и заменит собой документ в главном? или в разрезе каждого узла(включая главный) свое пространство айдишников? каким образом при обмене сопоставляются объекты?

Знаю, что прошу многого, но разбейте пожалуйста сабж на абзацы

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

ознакомтесь

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

если совсем быстро - создать пустую филиальную базу и загрузить в неё выгрузку(программно зарег изменения) из ЦБ

и не забыть подключить главный узел ;)

Это само собой) вся сложность в программной регистрации объектов. Хотя если план обмена типовой, то в ПрисозданииНачОбраза есть все процедуры по регистрации

прошу простить. действительно не особо читаемо, но возможности отредактировать сообщения нет. благодарю. подобные статьи уже начал изучать. с этим вопросов нет. пространство guid`ов общее в главном узле и подчиненных или в каждой базе свое? и повторю вопрос касательно очистки базы узла напрямую на sql. тот же truncate table. боком это может вылезти или нет?)

апну

Свое. Но зуб не дам. :-)

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

-> какие заняты, какие нет. Они генеряться при записи объекта. Свободные все которых еще нет :) -> мне быстрее почикать лишнее данные на скуле в данном случае да :)

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

т.е. чисто гипотетически возможно ситуация, что в двух подчиненных узлах может сформироваться одинаковый guid для объекта, так?) понятное дело, что вероятность маленькая. и вообще - они где нибудь хранятся? может какая нибудь служебная таблица базы на скуле

А теперь  вероятность этой ситуации раздели на то что по сути у объекта кроме гуида есть ещё и вид объекта (справочник номенклатура, документ реализация) И прикинь какова вероятность что в двух базах у двух документов одного и того же вида будут одинаковые ГУИЛы. Я согласен что она не нулевая, но всё же она настолько ничтожно мала, что ею все пренебрегают

т.е. у двух разных видов объектов может быть одинаковые гуиды, и программа при этом будет работать корректно

согласен. прошу простить за дотошность, но сами guid`ы где нибудь хранятся в базе? или это чисто "реквизит"-колонка в таблице на sql?