Жесткая связь таблиц.

[samonenko]

Как попроще решить такую задачу.
Пусть есть таблица Т1 с полями a1, a2, ... , an
заполненная данными.
Нужно сождать таблицу Т2 напимер с полями a1, a2 и a3
так, чтобы туда сразу внеслись сооветствующие данные из T1.
При этом, если эти данные менялись бы в T1, то они автоматически менялись бы и в T2.
Можно ли это реализовать без codunit ?
А если надо писать codeunit то как его получше написать?

[murick]

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

[Vukmut_imported]

Цитата:

Сообщение от сНЕЖНЫЙ_бес

Как попроще решить такую задачу.
Пусть есть таблица Т1 с полями a1, a2, ... , an
заполненная данными.
Нужно сождать таблицу Т2 напимер с полями a1, a2 и a3
так, чтобы туда сразу внеслись сооветствующие данные из T1.
При этом, если эти данные менялись бы в T1, то они автоматически менялись бы и в T2.
Можно ли это реализовать без codunit ?
А если надо писать codeunit то как его получше написать?

Если таблицы в одной базе, то:

Перенос данных таблицы, если в ней уже есть данные, можно поручить либо отчету типа "Processing Only", либо написать Codeunit, который выполнит перенос данных.

А для синхронизации (односторонней, насколько я понял из описания задачи) необходимо модифицировать триггеры OnInsert, OnModify и OnDelete исходной таблицы T1 и выполнять соответствующие измения в таблице Т2.

А по поводу "получше написать":
1. Цикл по перебору записей таблицы Т1 с вставкой записей в Т2
2. Подумать каким образом решить конфликт, если в таблице Т1 поля а1, а2, и а3 не являются альтернативным ключом таблицы, то есть можно найти две записи Т1, где значения полей а1, а2 и а3 совпадают. Это также относится и к синхронизации.

Могу ошибаться, но с версии 3.70 в Codeunit1 есть Триггер-функции, которые позволяют отслеживать именения данных в таблицах.

Если в разных: строить репликацию. Вариантов много.

ЗЫ: хорошая на тестовая задачка для начала предметного разговора на обеседовании

[romeo]

Цитата:

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

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

Плохой способ.

[Vukmut_imported]

Цитата:

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

Могу ошибаться, но с версии 3.70 в Codeunit1 есть Триггер-функции, которые позволяют отслеживать именения данных в таблицах.

Вот пришел домой и посмотрел (работаю сейчас не с Navision )

Не знаю как в 3.70, а вот в 4-ке точно есть триггер-функции OnGlobalInsert, OnGlobalModify, OnGlobalDelete, OnGlobalRename в Codeunit1, которым передается RecordRef, при помощи которого,в свою очередь, можно определить какая запись в какой таблице добавилась/изменилась/удалилась/переименовалась.

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

ЗЫ: а про один из триггеров я-таки забыл - OnRename. В нем тоже необходимо вставить процедуру синхронизации значений, если одно из полей, которое необходимо сохранять в Т2, находится в главном ключе таблицы Т1.

[smoyk]

Цитата:

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

Плохой способ.

Какой? Если вариант с триггером на сервере, то можно узнать, почему?

[RedFox]

Цитата:

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

Если таблицы в одной базе, то:

А для синхронизации (односторонней, насколько я понял из описания задачи) необходимо модифицировать триггеры OnInsert, OnModify и OnDelete исходной таблицы T1 и выполнять соответствующие измения в таблице Т2.

Если уточнить первичные ключи в обоих таблицах?
Если эти поля в первичных ключах (тоесть создаваемые записи уникальные), то вообще прописать тригеры как было указано ранее (только с проверкой на не существование уникальности) и проблем не будет.
При этом:
1. В свойствах полей Т2 (a1, a2 и a3) прописать ссылки на соответсвующие поля Т1
2. Написать единоразово отчет по перебору записей таблицы Т1 с вставкой записей в Т2
3. будут работать вышеописанные тригеры

[romeo]

Цитата:

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

Какой? Если вариант с триггером на сервере, то можно узнать, почему?

Вариант с триггером на сервере плох из-за того, что навиженовский судя по всему функционал реализуется не в навижене. Не обязательно создавать объект типа юнита. Ничто не мешает в триггера ведущей таблицы вписать код в триггера OnInsert, OnModify, OnDelete по синхронизации данных в связанной таблице. Зачем усложнять себе жизнь и лезть на сервер.
Писать кодеюнит не обязательно. Это отвечая на второе ваше предложение.
Вешать все это дело на таймер ЕЩЕ хуже. Попробуйте подебажить какую-нить форму, с написанным триггером OnTimer. А открывать ее все время в конструкторе, комментить триггер и пускать не сохраняя каждый раз руки отсохнут.

С моей точки зрения стандартные триггера OnInsert, OnModify, OnDelete ведущей таблицы вполне подойдут и это будет лучшим решением задачи. И самым естественным.

[smoyk]

To romeo
Хоть предложений и было 2, вопрос по сути был только один: чем плох триггер на сервере? Про кодюнит я не спрашивал
Но вот по поводу триггера... извините, но Ваш аргумент нельзя назвать серьезным. Хотя бы потому, что не факт, что это функционал именно нивиженовский. Вобще часто встречаю такие моменты, когда то, что должно быть реализовано в структуре самой БД делается через навиковский код. Этот случай еще туда-сюда, не совсем ясный, можно в принципе и так и так (имхо), но вот, скажем, когда ссылочная целостность в таблицах master-detail поддерживается на уровне навиковских триггеров... Кошмар!
Ну это лирика. Вы можете другие аргументы привести, почему не стоит поставленную автором топика задачу решать через серверные триггеры? Потому что даже если это действительно навиженовский функционал, не вижу ничего плохого в решении через сервер.

To RedFox
Да тема давняя, проблему наверняка уже решили Я ее поднял только чтобы прояснить интерисующий меня вопрос про триггеры...

[romeo]

Цитата:

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

To romeo
Хоть предложений и было 2, вопрос по сути был только один: чем плох триггер на сервере?

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

Цитата:

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

но вот, скажем, когда ссылочная целостность в таблицах master-detail поддерживается на уровне навиковских триггеров... Кошмар!

В этом весь навижен.

Цитата:

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

Вы можете другие аргументы привести, почему не стоит поставленную автором топика задачу решать через серверные триггеры?

Потому что можно решить навиженовскими методами. Причем не самыми замороченными. Форум навиженовский, я предлагаю варианты реализации в навижене.

[smoyk]

Цитата:

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

Форум навиженовский, я предлагаю варианты реализации в навижене.

Против этого трудно возразить