Справочник Контрагенты - реквизит брать из другой SQL базы #124485

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

Мда... Это твоё решение или так задачу поставили?

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

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

Штатно это не сделать. Да и нештатно тоже - идентификаторы элементов уникальны в пределах базы. А значит можно поиметь геморрой.Вариант "однообразия" - одна "эталонная" база, где и заводятся все элементы. И экспорт во все остальные базы оттуда.

>>сделайте в базах справочники тока на чтение и подгружайте регулярно из >>одной общей базы, в которой будут добавляться новые элементы.Этот вариант не подходит, т.к. любой вариант подгрузки может не запуститься, база может быть занята монопольно, да ещё много факторов кот. могут повлиять на данное задание. Да и вариант с любым экспортом тоже не катит, по тем же причинам.Если уж делать, то через компаненту 1С++, прямыми запросами к базе.может ещё будут какие нить решения данной задачи?

вот сам ты себе и ответил...если "центральная" база будет монопольно, не достанешь ты из нее данные, хоть через 1С*/

То 5. Ты знаешь сколько людей наступали на грабли, пытаясь писать что-то в базу в обход штатных процедур? Есть уверенность, что твое знание структуры данных позволит не получить удар граблями?

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

то 7. Мне не нужно ничего писать, ни проставлять нигде реквизиты. Я хочу, чтоб при обращении к реквизиту справочника 1с отрабатывала не стандартно, а выполняла sql запрос нужный мне. Чтоб, грубо говоря возвращялся реквизит находящийся не в данной базе а другой.

То 8. Такое же сообщение юзверь может получить и при переносе штатными средствами. Какая разница кто ему это сообщение выдаст?То 9. А если вторая база, к которой ты обращаешься в это время недоступна? Сам себе же противоречишь :) А как ты будешь синхронизировать элементы в двух базах? Что возьмешь за "точку опоры"?

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

Опять начинаешь с того, "сихронизировать не хочу", а затем "я буду искать по своему ID" :) Ты разберись что ты хочешь то.У тебя в базах данных есть некий элемент справочника. Во внешней базе есть другой справочник, которых синхронизирован с твоим по некому полю. Но у тебя несколько баз ссылаются на внешнюю. Кто установит соответствие элементов справочника в этих базах с внешней базой? Например во внешней базе есть контрагент "Рога и копыта". Как установить его соответствие десяти элементам "Рога и копыта" в других базах?

В каждой базе есть реквизит ID (это реквизит кот. я добавил в конфигураторе 1С). По этому реквизиту все уже синхронизированно. Эту проблему мы уже решили. Мы перехватываем выбор контрагенты и выдаем ТаблицуЗначений для выбора из базы "центральной", если выбранного контрагенты не находим, добавляем его в справочник программно. Теперь остается проблема с реквизитами данного объекта. У контрагента "Рога и копыта" меняется любой реквизит, ну предположим адрес. В рабочей базе его тоже нужно изменить. Так вот, я и хочу, чтоб данный реквизит, по своему ID находился в другой SQL базе и заберал от туда значение реквизита адрес.

"добавляем его в справочник программно." - добавляем в "центральной базе" или в локальной?Кстати ID - очень нехорошее наименование. У справочника есть штатный реквизит ID. Запутаешься потом.

Для справочников относительно несложно настроить репликацию.Можно конечно сделать и подмену реквкизитов но это будет не эффективно особенно в плане производительности.

На SQL - делается элементарно

То 15. А вот насчет элементарно - я бы поспорил.

На что?

10 баксов то не лишние...

"Я один, а они в ряд. Как пуговицы, насмерть!" (с) ЖванецкийБаза, где вводятся контрагенты - центральная, рабочие - перефирийные. Отредактировать _1sp_RegisterUpdate, чтобы в автообмен уходили только контрагенты.

То 20 . Я имел ввиду именно подмену.Синхронизацию реализовать действительно не сложно.

Дык! В постановке неявно указано, что структура баз индентична.

это не урбд. это обычные базы, в одном домене.

Структура одинакова? Тогда

да, блин... я же говорю, что вариант синхронизации мне не желателен. ЕСли говорить о синхронизации я её могу проводить DTS пакетами и не мучаться, с откатом транзаций и все такое ... Мне вот именно нужно чтоб инфа бралась из другой базы и всё.

...гхм!Посоветуй руководству поставить Axapta :)))А вообще, когда мне предлагают такое, обычно выхожу из кабинета, извинившись, возвращаюсь с чайной ложкой и с саморезм с крестовой шляпкой и напильником.Обычно хватает одной демонстрации.

это не важно, в SQL запросе можно все преобразовать и все нужные реквизиты найти.!!! ЭТО НЕ УРБД !!!

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

не понимаю сарказма. С аксаптой уже успел познакомится ... пожалуй не нужно нам такого счастья. Чуть успел ноги уволочь (перешёл на другую работу):)). А задача вполне нужная, и , я думаю выполнима, тока нужно понять направление, куда копать.

но ни невозможно?

Если сможешь сделать соответствие 1:1 во всех базах. Видимо, триггер на таблицу во всех базах, и в транзакции обновляешь запись (во всех базах, кроме изменяемой :-). На УРБД сделать легче.

А вообще-то задачка-то с душком или много травы под рукой :)

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

:) а подсказать направление движения?

напиши одну функцию, которая этим будет заниматься и её-то родимую везди и используй

как в рекламе "нежнее ... ещё нежнее" ... в нашем применении короче ... ещё короче ... А если честно ... в 10 базах переписать это гимор