Привет ! Я видел (но не разбирался) еще такую вещь - migrate3.dll как написано в описании " система по управлению обменом данными для 1С 7.7. Сайт указан http://www.info-tecs.ru

Z1 писал(а) 27. Сентября 2007 :: 05:29:

Оно надежное и простое. Этакий топор. Однако кое-кому иногда нужно выпиливать лобзиком.

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

Очень нужен перехват, а то приходится каждый раз изголяться встраивая вот этот перл http://infostart.ru/projects/402/ . А хотелось бы иметь возможность платформо, пардон, конфигурационно-независимо переватывать изменения объектов  развернуто, а не так куцо и бестолково как в стандартном журнале регистрации.

А вообще, мнится мне, что если писать обмен для 1С, то ни в коем случае не в 1С

freagle писал(а) 27. Сентября 2007 :: 20:19:

В моем случае базы - это не "Центр и периферия", это черно-белый учет. То есть обе базы активные, элементы могут создаваться в любой базе, правила пользователям объяснены, но иногда они забывают\ошибаются\бывают не в курсе\ещё что-нибудь... Тогда пользователю нужно вручную соответствие поставить, разорвать, изменить. Иногда бывает нужно просмотреть имеющиеся соответствия, разные косяки бывают. Типа - обличенный полномочиями, "особо умный" пользователь, слегка переименовал несколько элементов номенклатуры. Для такого просмотра, возможно, весь объем и не нужен, но это уже на выходе, а на входе, чтобы решить показывать строку или нет,  данные об объекте таки нужно по OLE вытянуть. В последнее время фича используется всё реже, так что просто забил.

Цитата:

Знаешь... Чтобы у объекта сменился IDDOC/ID -- я не встречал.
Если логически поразмышлять о возможности, причинах и последствиях такого события... Мне кааца, что ТиИ не сделает этого ни когда, причину придумать не могу, последствия
Если на объект были ссылки, то ТиИ исходный ИД должна сохранить, к примеру создать новую запись с ним. Тогда логически объект останется тем же, хотя наполнение в записи будет утеряно. Вот, кстати, тогда мой "просмотр соответствий" может помочь Цепляемся к неповрежденной базе и смотрим - кто же это на самом деле был? Но если в базе с переIDованным объектом ссылок на него не было - то в соответствиях будет битая "ссылка". Придется делать свою "ТиИ" для Соответствий

Но, согласись, что IDDOC/ID надежнее любого пользовательского реквизита? Или нет? Что думаешь использовать в качестве ключа?

Цитата:
Что имеется ввиду, не уже ли "Переносчик работает вне контекстов 1С соединяемых баз, а является самостоятельным приложением"? Ужос. Хотя, в контексте "69 баз", может быть лучшим решением.

Хранение соответствий объектов куда думаешь поместить?

ЗЫ: Последние три вопроса тесно связаны, ответ на один может сделать другой бессмысленным, это я понимаю.

Цитата:


Угу. примерно так. Есть такая мысль, и я ее думаю. Причем лучше даже не приложением, а системным сервисом. А задача 1С - только оповещать этот сервис об изменениях объектов. Нафига? Да очень просто:
1. Вынести всю логику обмена куда-нибудь подальше из 1С. Это позволит при меньших затратах получить доступ ко всему многообразию методов и компонент репликации данных, которые сегодня уже есть.
2. 1С будет заниматься чем ей и положено - обработкой бизнес-объектов.
3. Такое решение позволит раздельно менять бизнес-логику и логику обмена.
4. Если решение окажется удачным, его можно будет использовать на других системах с минимальными доработками - только на участках уведомления об изменениях объектов и загрузки объектов.

Дальше начинается мое имхо.
Все системы обмена для 1С грешат одним и тем же концептуальным пороком - ну нет в них, не проглядывается нормальный клиент - сервер. База, которая должна отдавать данные, является сервером. И должна быть готова отдать данные в любое время, а не тогда, когда после длительных раздумий выгружен "пакет данных", он же файл переноса данных, он же... Который становится устаревшим через пол-секунды после формирования. И начинается песня:

- Алло, Вася, ты мне какой последний пакет направил?
- 105-й.
- А у меня 104 только загрузился.
- Не знаю, смотри почту.
- Да смотрел я, ничего нет

... наконец, нашли пакет, и опять:

- А почему в нем нет документа №xxxx? (марья ивановна сказала, что отгрузила на нас товар...)

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

Я никогда не думал что выучусь так многоколенно материться.

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

Именно поэтому я и говорю - желательно оформить сервисом. Если пользователю позарез нужен документ и абсолютно нехрен кроме этого делать - пусть сидит и дыргает кнопочку "Обмен". Сервис, если нет для него данных будет стабильно возвращать ответ "А нету, родной, для тебя ничего..." А как только появятся - начнет отрабатывать передачу. Но! это будет только по запросу клиента, а не "по расписанию"

Теперь представим, что одновременно хотя бы двум  пользователям вставило именно сейчас получить данные. А это сразу же - параллельная обработка, то есть - диспетчеры запросов, очереди, потоки... То есть то, что на 1С, даже с применением 1С++ (простите, разработчики, не гневайтесь на правду...) нормально не сделаешь.

Поэтому и "внешнее приложение", точнее, сервис...

Цитата:


А можешь подсказать как в УРБД реализовать следующее: документ "Реализация (комиссия)" должен в периферийной БД стать "Поступлением ТМЦ (комисиия)", и создать для себя партии, а не хватать те, которые пришли по обмену?