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

[Кирен]

Здравствуйте!

Есть задача: передать запись таблицы из одной компании в другую.
Это действие желательно выполнить в момент сохранения записи.
Поскольку запись передать нельзя, передаётся значение ключевого поля таблицы.
И тут возникает проблема: если действие по синхронизации выполнять в триггере OnModify, то запись ещё не сохранена и в таблице хранятся старые значения полей.
Можно, конечно, вызвать CHANGECOMPANY, но тогда надо делать CHANGECOMPANY для любой таблицы, для которой необходимо выполнять проверки полей (например, наличие глобального измерения в фирме-приёмнике).
Поэтому передаётся значение ключевого поля в фирму-приёмник и там уже вызываются стандратные проверки.

Можно ли каким-то образом принудительно сохранить передаваемую запись?
(MODIFY на триггере ONModifyRecord формы и OnModify таблицы не дало ничего).

Или есть какой-то способ имитировать работу триггера OnAfterModify?

[romeo]

Репликация?

[rmv]

Как же быть со вставками и удалением записей? Боюсь в такой постановке задача нерешаемая.
Возможно лучший вариант пересмотреть концепцию и валидэйтить записи в фирме-приемнике на триггере OnModify:
ReceiverRecord.changecompany(ReceiverCompany);
ReceiverRecord.transferfields(SenderRecord, true);
ReceiverRecord.CheckRecord;
if not ReceiverRecord.insert then
ReceiverRecord.modify;

[romeo]

Кстати, может таблицу общефирменной сделать? )))

[Кирен]

Цитата:

Сообщение от rmv

Как же быть со вставками и удалением записей? Боюсь в такой постановке задача нерешаемая.
Возможно лучший вариант пересмотреть концепцию и валидэйтить записи в фирме-приемнике на триггере OnModify:
ReceiverRecord.changecompany(ReceiverCompany);
ReceiverRecord.transferfields(SenderRecord, true);
ReceiverRecord.CheckRecord;
if not ReceiverRecord.insert then
ReceiverRecord.modify;

Этот вариант мне непонятен.
Как инициировать процесс синхронизации в фирме-приёмнике если изменяется запись в фирме-источнике?
Триггер OnModify сработает в фирме-источнике на той записи, которая была изменена.

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

Цитата:

Сообщение от romeo

Кстати, может таблицу общефирменной сделать? )))

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


Пока что всё свелось к более простому варианту с использованием NAS.
При изменении устанавливать флажок(в таблице, которая хранит значения первичного ключа таблицы и тип синхронизации=Вставка,Изменение,Удаление), что запись была изменена.
И по таймеру запускать процедуру синхронизации.
Досконально этот способ проверю чуть позже.

[rmv]

Если синхронизировать нужно немедленно после изменения записи - процедуру инициализации синхронизацию нужно переложить с фирмы-приемника на источник. Физически запись в приемнике обновится раньше, чем в источнике.
Если временной лаг допустим - вариантов множество:
От ведения лога до анализа таймстампов в версии SQL.

[Sancho]

а можно совсем немножко про бизнес процессы...
что за таблицы? к чему такая онлайн спешка?

Рома правду говорит, некоторые справочники и общефирменными можно сделать, а некоторые документы по МФ функционалу лучше запускать

[Васыо]

Кстати, помимо МФ функционала есть очень интересный функционал RIM. Я сейчас не на работе, диапазона объектов не помню, но что-то в районе 8000 с чем-то. Выгружает таблицу в xml, а потом в другой базе без проблем загружает. Остается только фильтры поставить и, если надо, счётчики.

[Васыо]

Форму 8627 посмотрите. А функционал Migration называется.

[Кирен]

Цитата:

Сообщение от Sancho

а можно совсем немножко про бизнес процессы...
что за таблицы? к чему такая онлайн спешка?

Рома правду говорит, некоторые справочники и общефирменными можно сделать, а некоторые документы по МФ функционалу лучше запускать

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

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

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

Цитата:

Сообщение от Васыо

Форму 8627 посмотрите. А функционал Migration называется.

Спаибо большое за подсказку
Оказалось, что эту функциональность я в первый разу вижу.

Но, пожалуй, эта функциональность не совсем подходит.

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

[Sancho]

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

[romeo]

Цитата:

Сообщение от Sancho

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

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

[Кирен]

Sancho, примерно так сейчас и реализовала синхронизацию одного из справочников.

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

Может затем, чтобы не было "забытых" заданий по исправлению ошибок синхронизации?

[rmv]

Кстати, фирма-источник одна, или записи должны гоняться в обе стороны?
И какая необходимость (не сочтите за нескромность ) учитывать документы несколько раз в разных фирмах?
Коли аргумент romeo руководство использовало как дополнительный довод в пользу онлайн синхронизации - может стоит сместить акцент и вести речь о механизме параллельного учета документов в разных фирмах, онлайн синхронизация документов и справочников здесь только один из вариантов.

[Storkich]

Цитата:

Сообщение от Кирен

Поскольку запись передать нельзя, передаётся значение ключевого поля таблицы.

Заблуждение, передаются все поля.

В инсерте и модифае

ReceiverRecord := Rec;
ReceiverRecord.changecompany(ReceiverCompany);
if not ReceiverRecord.insert then
  ReceiverRecord.modify;

[Кирен]

Цитата:

Сообщение от Storkich

Заблуждение, передаются все поля.

Нужны validat'ы полей в фирме-приёмнике.
Отработают ли они нормально в фирме-приёмнике?

Для дополнительных проверок понадобится делать CHANGECOMPANY для каждой из проверяемых таблиц.
(Например, проверка - наличие глобального измерения в фирме-приёмнике).

[Кирен]

Цитата:

Сообщение от rmv

Кстати, фирма-источник одна, или записи должны гоняться в обе стороны?
И какая необходимость (не сочтите за нескромность ) учитывать документы несколько раз в разных фирмах?
Коли аргумент romeo руководство использовало как дополнительный довод в пользу онлайн синхронизации - может стоит сместить акцент и вести речь о механизме параллельного учета документов в разных фирмах, онлайн синхронизация документов и справочников здесь только один из вариантов.

Фирма-источник одна.
Синхронизация односторонняя. Вроде
в одной фирме документ содержит 5 строк, во второй - 3.
И с другими аналитиками, например. С другим количеством.
Это, конечно, слабая отговорка, но я могу не знать всех требований, поскольку не я контролирую этот процесс.

[rmv]

Цитата:

Сообщение от Кирен

Фирма-источник одна.
Синхронизация односторонняя. Вроде
в одной фирме документ содержит 5 строк, во второй - 3.
И с другими аналитиками, например. С другим количеством.
Это, конечно, слабая отговорка, но я могу не знать всех требований, поскольку не я контролирую этот процесс.

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

[apanko]

Цитата:

Сообщение от Кирен

Фирма-источник одна.
Синхронизация односторонняя. Вроде
в одной фирме документ содержит 5 строк, во второй - 3.
И с другими аналитиками, например. С другим количеством.
Это, конечно, слабая отговорка, но я могу не знать всех требований, поскольку не я контролирую этот процесс.

Что делается и зачем довольно понятно.
Но вот онлайн для этих целей не нужен. Раз в месяц синхронизировать периодическим заданием и нормально. Максимум раз в неделю.

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

[Кирен]

Цитата:

Сообщение от rmv

А Вам Кирен удачи в разгадывании ребусов, думаю Вы ошиблись форумом, похоже Вам сюда

Ну что же - - спасибо.
Юмор оценила.