Галактика в вопросах и ответах

Настроил корпо-обмен, состоящий из корпо-сервера и четырех клиентов, удалил везде журналы, почистил папки обмена, удалил зарегистрированный обмен с сервером и клиентами. Вроде все чисто, НО при запуске "Работа" на сервере он сыпит почту клиентам (не нужную) и все ломает. Отсюда первая проблема: где еще кроме журнала при корпо обмене хранятся записи?
Вторая проблема. У меня есть обмен по запросу, а именно ходят накладные, предназначенные для определенного клиента. Запрос следующий: KATSOPR.CPODRTO = KATPODR.NREC AND KATPODR.CGRPODR = 4001039BB3352876h; Клиенту все уходит нормально, но если там эту накладную правят, то она почему-то возвращается, хотя не удовлетворяет запросу. Почему? Как следать, чтоб не возвращалась?
Третья проблема: (вытекает из второй) Как сделать так, чтоб некоторые записи не уходили по обмену. Т.е. нет ли возможность запретить в журнале записям реплицироваться?
Ну и, наконец, отключаю журнализацию, но все равно пишется все в журнал. Кто знает, в чем может быть проблема, хотя бы частично, помогите, очень нужно.
Pervasive 8.6, Галактика 712, Support 4.35.22 (патчи ATL02, ATLBTR01, SUP02).

Хм. в целом по корпо: изначально этот функционал предназначался для ПОЛНОЙ СИНХРОНИЗАЦИИ двух и более баз данных. При попытке делать репликации по условиям и т.п. возникали проблемы.

С журналом - может быть почистить журнал и в журнализации и в модуле КОРПО ?

Вот, это-то я и не знаю, что за журнал в модуле корпо?

Что касается ПОЛНОЙ СИНХРОНИЗАЦИИ.
Зачем в каждом подразделении нужны накладные другого подразделения? Не говоря уже про бухгалтерский контур и зарплату. Если материаллы переходят на другой склад, то использунтся внуртеннее перемещение, также едины основные справочники. А полная синхронизация с нашими каналами связи и размером базы вряд ли возможна.
Все-таки, подскажите имя таблицы журнала в модуле корпо.

полная синхронизация имелось в виду что, если документы из филиала отправляются в центр и там с ними производят изменения (достаточно зайти в документ что бы сделать изменения) и эти документы по корпо не отправляются обратно в филиал, то последующие измения этих документов в филиале не дойдут до центра. Можно не спрашивать почему. Со справочниками такая же история.
Журналы используемые корпо X$JOURNAL и SERVERJOURNAL

Спасибо

Как сделать так, чтоб некоторые записи не уходили по обмену. Т.е. нет ли возможность запретить в журнале записям реплицироваться?

Только запросами.

отключаю журнализацию, но все равно пишется все в журнал.

Журнализация и репликация - разные вещи. При этом таблица для них одна - journal.adf. Если журнализация отключена, но включена репликация, записи, удовлетворяющие настройкам репликации, сыпятся в эту таблицу.

Клиенту все уходит нормально, но если там эту накладную правят, то она почему-то возвращается, хотя не удовлетворяет запросу. Почему?

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

если документы из филиала отправляются в центр и там с ними производят изменения (достаточно зайти в документ что бы сделать изменения) и эти документы по корпо не отправляются обратно в филиал, то последующие измения этих документов в филиале не дойдут до центра.

Никогда с таким не сталкивался.

При попытке делать репликации по условиям и т.п. возникали проблемы.

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

Serges писал(а):А вообще, без корпо конечно лучше, планируем изжить

А что вместо планируете?? Или изжить совсем из схемы работы

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

Потому что в условии KATSOPR.CPODRTO = KATPODR.NREC AND KATPODR.CGRPODR = 4001039BB3352876h; в разных подразделения nrec разный, т.е. из подр1 в подр2 уходят накладные только для подр2, а из подр2 в подр1 уходят накладные только для подр1. Т.е. одна накладная должна идти в одном направлении (я так думал), но если ее удаляют в месте назначении, то почему-то она удаляется и у отправителя.

Oweo писал(а):А что вместо планируете?? Или изжить совсем из схемы работы

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

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

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

Причём, обмен односторонний, только из чёрной в белую, из белой в чёрную обмена нет. Если интересно как настроено, расскажу поподробнее!

По поводу того где хрянятся записи для отсылки из черновой базы:
1. Хранятся они в журнале.
2. Хранятся в файлах *.mna (случай если при предыдущем запуске изменения не передались).

Вот вы пишите что сервак засыпает клиентов ненужными записями, верно? Странно звучит, ибо передаватьсся должно только то что вы хотите передавать, и больше ничего! У меня передача накладнушек настроена например по номеру накладной, точнее по префиксу номера, если префикс "/э", то в одну базу, если "/у" то в другую соответственно. Платежи например передаются по номеру банка плательщика. И т.д.

По поводу того что почта из белой вносится в чёрновую!

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

Дело не в том, что шлются ненужные записи, а в том, что если сделаны изменения в пришедшей почте, то эти изменения уходят назад, хотя по условию не должны. Причем эта проблема подтвердилась и отправлена в Галактику.

Есть у нас также черновая база с полностью одностороннем обменом (не по условию), так там все нормально работает.