Подбросьте идею по синхронизации объекта между филиалами...

[Александр]

спасибо конечно за доверие
Но главное что-что руководством поставлена конкретная задача (что согласитесь уже само по себе требует уважения), а это значит только одно - что задача будет решена

а пока продолжаю собирать идеи я думаю все получится

[Artem]

поставленная задача видится нечётко
исходил из следующих данных:
- нужно работать с несколькими филиалами, объединяя данные посредством репликации;
- не все проекты в совместной работе - т.е. количество филиалов варьируется.

Представим себе объект, у которого есть ряд атрибутов, формируемых из данных разных филиалов. У этого объекта создаются дочерние объекты, состоящие из атрибутов, значения которых варьируются от филиала к филиалу. В ряде случаев добавляются атрибуты даты изменения значения отдельно взятого атрибута - для того чтобы можно было в родительский объект выбирать самые актуальные данные, в зависимости от логики работы. Актуализацию данных проводить действием (запускаемым на сервере с СУБД) после репликации.
т.е. вариант Alexey'а

Репликация работает следующим образом:
- данные объектов с совпадающим ID перезаписываются
- ID включает в себя номер филиала, поэтому объекты при первой репликации пересечся не могут, а вот когда объект "возвращается" с другого филиала с изменёнными значениями атрибутов - репликация перезапишет эти данные в исходном филиале

[Старик Крупский]

Репликация работает на уровне таблиц. Есть таблица и есть идентификатор (первичный ключ). И погнали. Все пересечения по ключам переписываются. Это абсолютно нормально и правильно. Лоция просто дает свой интерфейс отбора данных, чтобы в таблицах самому не ковыряться. Идея с кол-вом атрибутов кратным кол-ву филиалов крайне непривлекательна именно из-за неопределенной кратности. Сегодня два филиала, а завтра один или четыре, а потом второй закрыли и вместо него открыли пятый. Оно нам надо?
Если честно, мне не совсем понятно, как с одним клиентом можно работать одновременно в разных филиалах (городах?). Справочник клиентов может быть и единым с однонаправленной репликацией из центра в филиал, но не обязательно - у филиала могут быть свои "кормильцы" и тогда они пойдут из филиала в центр. Мероприятия по клиенту уж точно разные. Ну нельзя клиента с двух сторон "сделать в одно место". Если кто мою фразу воспримет неправильно - тот извращенец
Разбивайте мероприятие на составляющие и пусть каждый филиал ведет свое мероприятие или что там у него...

[Александр]

Что самое интересное - клиента можно и нужно ... с разных сторон
Простой пример Центр-это мы, филиал - это учебное заведение...
Мы нашли клиента приняли от него заказ - записали данные контакты и т.д. (создали проект) и бросили его в учебный филиал (репликация) - там с ним начали работать по своему... в то же самое время, тот же самый клиент выставляет какие то заказы центру... и дополнительно по прошествии обучения в филиале клиент возвращается (репликация) обратно в центр для проведения маркетинговых мероприятий по накопленной информации

Что получаем в итоге
1. Есть общая контактная информация (пара объектов клиент/контакт с атрибутами)
2. Есть действия совершаемые в филиалах, оформленные в виде своих непересекающихся объектов (в центре заказы-свои объекты, в филиале учеба-свои объекты)
В чем проблема на сегодня
1. Риск изменения общей контактной информации - мы записали один адрес, а филиал исправил его на другой и вернул нам
2. Риск перезаписи общего информационного атрибута
Мы на текущий момент фиксируем в специальном атрибуте все ключевые телодвижения клиента т.е. он говорит - хочу купить-мы создаем отдельный объект ХОЧУ и дополняем специальный информационный атрибут клиента тем что - такого то числа такой то чел сказал хочу купить (строка). В результате этот атрибут в центре заполняется своей информацией+ свои объекты, а в филиале тот-же атрибут -своей+плюс уже свои, филиальские объекты - поэтому я и предполагал их (атрибуты активности по филиалам) разнести чтобы случайно не перезаписать (данная задача - информация о ключевых событиях клиента-может быть собрана и отчетом по объектам- но руководство сказало что она должна быть видна сразу в виде отдельного текста)

Кстати сбербанк/страховщики и т.д. действуют по аналогичной схеме (к сожалению не на Лоции)
один клиент-миллион филиалов-все работают с клиентом на местах-вечером (или сразу) сливают информацию в общую базу...
Причем при изменении некоей общей информации - оператор, если ему разрешено редактирование, должен описать причину изменения, и в случае внесения недостоверных данных-ответить по полной программе

выход наверно только один
1.на каждый атрибут(или группу атрибутов) с общей информацией - добавить атрибут - изменений - кто когда и почему (если бы можно было использовать атрибуты истории Лоции в расширенном варианте- с сохранением предыдущего значения атрибута-это бы подошло))
2.в каждом филиале все действия оформлять в виде самостоятельных объектов (которые инициируются и 'закрываются' только в своём филиале)
3.информацию о 'активности' накапливать не в общем информационном атрибуте а получать отчётом

тогда пересечений нет, все просто, но добавляются атрибуты изменений общей информации

Идея Алексея о версионности объекта по филиалам с последующим наследованием варианта - мне честно говоря- совершенно не нравится - много 'двойников'
Идея Артема о создании служебного объекта с атрибутами изменений по филиалам - усугубляется только тем - что это оформлено в виде отдельного объекта который будет доступен (виден) в дереве проекта, и будет отвлекать.

Извиняюсь конечно за критику
но вариант Крупского с отдельными объектами и вариант сбербанка с атрибутом о причине изменения атрибута(ов) мне кажется наиболее перспективным - один проект+куча объектов из филиалов+ общая для всех информация с историей кто зачем и с какого перепуга изменил обшие данные какие мы считали достоверными

но... и здесь проблема - атрибут хранящий историю о факте изменения атрибута - тоже является общим

Давайте сузим задачу
как использовать общий атрибут о факте изменения общей информации и не перетереть его во время репликации

[Старик Крупский]

Что-то забрезжило в моем сознании... пытаюсь нащупать ниточку, а она ускользает........... Короче, Александр, фантазия у тебя есть, а я край ниточки тебе брошу. Подумай вот над чем: сделай базу для филиала у себя и у себя же создай им пользователей. А раз у тебя их пользователи, значит, у тебя и командный пункт по раздаче прав. Короче, как-то надо извернуться, чтобы не давать в филиала пароль админа. Сайбейсовскую базу, что ли кинуть им... А можно поставить им отдельную копию MS SQL и не давать пароль sa. Сделай какого-то юзера админом по набору привилегий, но не давай им права на общие атрибуты. Чуешь, куда я клоню... Додумывай

[Александр]

нет, к сожалению не то
-базу мы им уже купили MSSQL 2005 (сами используем MSSQL2000)) -администрировать ее я буду удаленно ( в смысле пароля админа у них не будет)
...и правами здесь дело не решить ведь общий(е) атрибут(ы) например адрес(реквизиты) должен иметь возможность свободного редактирования/дополнения как на той, так и на другой стороне
....
хотя
....
все-таки вариант с одинаковыми по смыслу но персональными по филиалам атрибутам мне нравится все больше и больше. (в принципе это тоже самое что предлагали Алексей и Артем, вид сбоку, но применительно к атрибутам а не к объектам)
и в них можно хранить как общие /персональные данные так и их изменения да и все что угодно (кстати и в виде массива с использованием наших отработанных хп это вообще смотрится прекрасно )
...
это все сработает при одном условии - если на отдельные атрибуты объекта можно дать персональные права по филиалам надо попробовать

Наверно поступлю следующим образом
1.
- известно что филиалов в ближайшем будущем будет не более 3х
- известны 'критические' наборы общих данных, достоверность которых обязательна. (Таких наборов у каждого объекта 1~2шт при общем количестве его атрибутов порядка 10~50 шт.)
2.
таким образом для каждого набора данных (набор -это то что редактируется в одном действии (свободное редактирование у нас запрещено)) я повешу три строковых атрибута с историей изменений по филиалам
3.
принимая то обстоятельство что данные из набора всегда правильные независимо от количества репликаций - мы можем начать совместную работу в любой момент обратившись к истории изменений внесенных тем или иным филиалом
т.е. общие данные перетираются всегда а атрибуты изменений - никогда (в том плане что они конечно тоже перетираются всегда-но изменить их может только тот или иной филиал)
4.
в будущем, мне кажется не составит труда уйти с такой схемы работы без потери накопленной информации или если понравится просто добавить еще атрибутов под новые филиалы

в общем пошел разбираться с персональными правами на атрибуты с привязкой к филиалу

ps Крупский! спасибо за идею!

[Александр]

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

[Старик Крупский]

Слушай, а расширенный импорт катит? Его вообще можно с командной строки запускать..

[Александр]

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

[Александр]

...да и руководство вроде одобрило...
Эх жалко что Андрей репликацию не использует - такая приятная вешч скажу я вам вот только денег как всегда нету на всякие глупости

[Старик Крупский]

Вот так всегда на глупости нету, а на женщин есть