Двустороння репликация средствами SQL-Server. При настроенной РБД #364516

Помню в в77 это было невозможно, потому что при репликации СКЛ-сервер  в базе-приемнике как-то менял служебные поля, что в77 воспринимала настолько тяжело, что отказывалась работать с базой... Теперь стоит такая задача - между двумя базами, на которых настроена РБД (план обменов), чтобы в8 всегда знала в какой базе какой объект создан, и двусторонним обменом средствами 1С раз в сутки, можно ли настроить двустороннюю диференциальную репликацию средствами СКЛ-сервера? то есть - не будет ли повторяться ситуация характерная для в77?

СКЛ никакие поля не меняет, а добавляет свои, на это 77 и ругалась. Есть 8ка не против дополнительных полей в своих таблицах, то возможно и взлетит.

Для одной и той же конфигурации в разных базах 1С поля могут называться по-разному (например, после выгрузки/загрузки конфигурации имена полей в таблицах SQL могут поменяться). Так что не взлетит.

Господи, что, правда? Но погоди-погоди... а если я вторую базу получу полной репликацией первой - тогда ведь имена полей будут теже самые - верно? Мне только нужно будет сказать каким-то образом в реплике что это уже узел не главной базы, а перефирийной...

"после выгрузки/загрузки конфигурации имена полей в таблицах SQL могут поменяться" - извини, но фигню сказал.

совсем не фигня. таблицы именуются при развертывании базы, и в разных базах одни и те же объекты 1С могут по разному называться на SQL уровне. проверено.

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

Можно сделать снимок SQL, подключится 1Сом и установить главный узел. Правда как боротся с "ЭтотУзел" не знаю, не связывался.

Вот кусок выгрузки семерочной базы: {"References", {64, {"6|","0|","","IT-директор","0|",0,0}, {"1|","0|","","Арт-директор","0|",0,0}, 64 - это ИД-ник справочника "Должности". И таблица, соответственно называтеся SC64. И после загрузки она будет называться именно так же. Так что, что-то не то у вас проверено :)

Тему читаем? "v8: Двустороння..."

нет, не стоит этого делать. 8.х не любит нестандартную структуру таблиц

для реплики 1С средствами SQL лучше всего использовать зеркало по логу транзакций(правильное название не помню) т.к. оно НИКАК не влияет на работу самой БД.

Понял, отстал :) Был не прав.

Я пока не понимаю на каком этапе появляется нестадартная структура... (10,11) Ну смотрите я могу создать первоначальный снимок как средствами в8, так и средствами полной репликации СКЛ-сервера... в первом случае возникает эта коллизия с другими именами таблиц/полей? Если даже да, то ведь остается второй способ, нужно только придумать как обмануть ЭтотУзел (см.8), но мне мое дежавю подсказывает, что что-то подобное я уже делал, щас вспомню как... Если этот спотык мы разрешаем, то у нас на данном этапе появляются две базы с одиакноковыми именами таблиц/полей, которые знают дряг про дурга кто из них центральная база, кто перефирийная... И тогда уже диференциальная репликация не составит труда, верно? вопрос останется только как будет себя вести обмен данными средствами в8 который планируется раз в сутки? То есть не задвоятся ли данные, к примеру?

кажется нужно пробовать... :)

Данные по уникальному идентификатору проверяются, наврядли они задвоятся. Хотя, возможно, создание других имён таблиц для другой базы позволяет разрешать коллизии с создание двух объектов в двух базах с одинаковых УИД. Проверяйте. Интересно будет результат почитать. Я тоже пытался придумать хитрую репликацию и в результате пришел к выводу: бэкапить ночью центральный узел средствами 1С(через .bat файл), а переферию, в случае падения, просто перегенерировать. Правда мне это позволительно, т.к. переферия это только часть центра, там нет информации ТОЛЬКО для перефериии.

У нас д.б. аналогично (в переферии НЕ д.б. инфы ТОЛЬКО для перефирии)

тоже спасибо, почитаю

Обсуждение уже было: РИБ-обмен (от 1С) и SQL-репликация - две разные и несовместимые вещи. Лучше не связываться :( Первоначальный образ дочернего узла можно создать из "полной" копии центрального узла - если все данные участвуют в обмене. В дочернем узле после этого надо "поменять" коды и наименование местами в описание узлов...

2 точно, про коды и наименования в узлах - это как раз оно, спасибо... === а вот почему РИБ-обмен и СКЛ-репликация несовместимые вещи - непонятно. есть ссылки на обсуждения?

совместимые, если долго мучиться