Lotsia PLM: Форум по семейству систем PLM/PDM/TDM/ERP/Workflow

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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