Репликация БД и Лоция

[niik]

Уважаемые форумцы. Объясните зачем нужен модуль репликации для Лоции. Есть средства репликации самой БД - зачем платить деньги?

[Эд]

Это смотря что вы хотите получить. Если задача перегрузить одну БД в другую один к одному, то денег платить не надо.
А если надо перегружать (или регулярно обновлять) только часть информации (шаблоны, отчеты, проекты и т.п.), тогда либо деньги платить, либо самому писать.

[niik]

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

[Loco]

В Лоции судя по всему репликация основана на загрузке и выгрузке пакетов

Так вроде бы репликация как раз и подразумевает загрузку и выгрузку пакетов для обмена данными между базами.

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

[niik]

Самое интересное, что если коннект прервлся то, то те кто удалены от БД с ней работать не смогут.
Репликация подрузамевает, что если нет коннекта то работает каждый со своей базой,а как коннект появился обменялись данными, ведь SQL2000 потом в соответствии с привелегиями серверов БД урегулирует конфликты(по крайней мере должен)

[Эд]

что-то непонятно мне, что вы, уважаемый niik, хотите. Тему создали про репликацию, потом пишете, что хотите работать в on-line. Если у вас есть возможность работы в on-line, то не нужно заморачиваться репликацией.
Если нет возможности поддерживать устойчивый коннект, то нужна репликация. Для этого она и создана.
Что касается "выравнивания конфликтов sql-сервером", то это, imho, иллюзия, что подтверждается нехилым количеством вопросов по конфликтам репликации на сертификационном экзамене.
Ну и наконец непонятно, что именно вам нужно: синхронизировать БД один к одному или обмениваться частью информации - это тоже немаловажно.

[Loco]

Вернемся к началу темы.
Вопрос "зачем платить деньги" для себя я решаю так: если можно не платить, то нужно не платить.
Лишь бы потом убиваться на работе не пришлось.

[Александр]

Сейчас намечается острая необходимость передать, пользовательское действие из базы в базу, именно действие или всю настройку целиком, не сами данные (хотя конечно они являются теми-же данными).Без приобретения модуля репликации от Лоции.

Причины очевидны, по крайней мере для нас
-распространение своей настройки (пустая модель с действиями и шаблонами) в дополнение к тем - что представляет Лоция
-обмен решениями между пользователями системы

Как вы считаете, стоит ли повесить эту тему на голосование как расширение функционала или модуль репликации решает эту проблему? -выделение из рабочей системы - пользовательской настройки? или отдельного действия/шаблона/работы?

[Anderyt]

все таки для этого есть модуль репликации... НО! если вспомнить, что действия хранятся в БД... можно вытащить строки с описанием нужных действий из одной базы, потом вставить их в другую, каким то хитрым образом при этом разобравшись с ИД действия... только аккуратно

[Александр]

Техподдержка ответила что - есть процедуры для выделения 'пустой' настройки - но они доступны только для партнеров. Остальное действительно делает репликация. Хотя согласитесь было-бы приятно обменяться с кем нибудь своими 'действиями'-НО конечно при этом можно запросто получить и 'трояна'

[Юрий]

У репликации есть небольшой нюанс - для того, что-бы все объекты базы (объекты, действия и т.д.) нормально передались в другую базу они должны создаваться в базе источнике с установленным кодом филиала отличном от кода филиала базы приемника. Это из-за принципа формирования идешников базы. Если коды совпадают то есть большая вероятность перекрытия данных и данные в базе приемника могут быть затерты реплицыруемыми данными. Исходя из этого можно смело перекидывать действия созданные в базе с другим номером филиала средствами SQL в другие базы. Но эта база должна вестись изначально с другим номером филиала, тот кто будет переносить данные должен быть уверен в том, что он разобрался в структуре хранения и перенесет все необходимые данные данные.
Обработать идешники можно, но для этого надо разобраться в принципах формирования идешников, вовторых есть маленькое неудобство - все формы хранятся в виде текста и для того. что-бы в них изменить ссылки нужно дополнительно разобраться в формате хранения.

[Александр]

Да в том-то и дело что вопрос формирования ID по большому счету остается неизвестным, с форматом формы вроде все прозрачно. Но я тут подумал, имеет ли смысл передавать действия в другую базу если есть возможность (у партнеров) передать свою настройку целиком. Т.к. при передаче отдельно взятых действий попадаешь на разные структуры данных разные типы объектов отсутствие или дублирование атрибутов и еще много всего.

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

[Юрий]

Вопрос формирования ID будет несложным, если за его выяснение возмется хороший специалист по базам SQL.

[Александр]

так в чем проблема? все мы здесь работаем на энтузиазме

[Юрий]

Решение проблемы:
1. Создаешь две базы с разными филиалами.
2. Настраиваем репликацию данных между ними на уровне SQL сервера.

И все. В таком варианте тебе и даром ненадо знать, как формиоуются идешники.