MAP в качестве datasource формы

[IKA]

Есть 2 таблицы Т1 и Т2, у них есть с 2 десятка одинаковых полей и с десяток разных.
Есть форма, на ней основной datasource основан на Т1 и в зависимости от текущего значения поля vendAccount записи этого основного DS, нужно в некоторых полях формы показывать данные либо из Т1 или из Т2 .

Допустим, vendAccount = 001 , то в поля формы F1....F20 отображаться значения из Т1 , vendAccount = 002 , то в те же поля формы F1....F20 отображаться уже значения из Т2.

Хочу положить на форму map , в котором замаппены эти 20 полей из T1 и T2. Как это лучше сделать? Просто указать этот map в качестве DS2 формы и на linkActive заполнять присваивать строке map знания из нужной таблицы ? Или умней сделать как-то по-дугому?

[ZVV]

Цитата:

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

Есть 2 таблицы Т1 и Т2, у них есть с 2 десятка одинаковых полей и с десяток разных.
Есть форма, на ней основной datasource основан на Т1 и в зависимости от текущего значения поля vendAccount записи этого основного DS, нужно в некоторых полях формы показывать данные либо из Т1 или из Т2 .

Допустим, vendAccount = 001 , то в поля формы F1....F20 отображаться значения из Т1 , vendAccount = 002 , то в те же поля формы F1....F20 отображаться уже значения из Т2.

Хочу положить на форму map , в котором замаппены эти 20 полей из T1 и T2. Как это лучше сделать? Просто указать этот map в качестве DS2 формы и на linkActive заполнять присваивать строке map знания из нужной таблицы ? Или умней сделать как-то по-дугому?

А вы пробовали указать Map в датасорсе формы?
Думаю придётся делать через временню таблицу, или через два табПэйджа (один, для ненужной таблицы, скрывать)..

[IKA]

Цитата:

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

А вы пробовали указать Map в датасорсе формы?
Думаю придётся делать через временню таблицу, или через два табПэйджа (один, для ненужной таблицы, скрывать)..

AX2009 - можно выбрать map в качестве DS формы.
вопрос - как потом с ним работать...

[Ruff]

Цитата:

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

Допустим, vendAccount = 001 , то в поля формы F1....F20 отображаться значения из Т1 , vendAccount = 002 , то в те же поля формы F1....F20 отображаться уже значения из Т2.

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

• создать свой Enum, который будет отвечать за выбор этих двух таблиц. Что-то типа MyVendType::T1 и MyVendType::T2 (с осмысленными названиями, разумеется);
• добавить в таблицу T1 поле с типом MyVendType и единовременно (job-ом) заполнить это поле на основе поля vendAccount в соответствии с Вашей логикой. При этом не забыть модифицировать код, выполняемый при добавлении записей в таблицу (инициализация поля MyVendType);
• добавить к таблице T1 два отношения (relation): одно с самой собой, а второе - с таблицей T2. Эти отношения должны иметь тип связи "поле фиксировано" и строиться на поле MyVendType. (В первом случае связь будет MyVendType == 0, во втором - MyVendType == 1);
• добавить в упомянутые отношения связи по первичным ключам (однозначно идентифицирующие запись);
• на форме создать три источника данных: родительский T1 и два подчиненных: T1 и T2, и привязать их к разным TabPage, как советовал ZVV выше.

Получилось на первый взгляд громоздко, но зато: 1) не навешиваются доп. действия на linkActive (может я не прав, но имхо, нагружать этот метод - это совсем крайний случай), и 2) используется стандартный механизм динамического выбора источника данных (если это можно так назвать).

PS: если мое описание покажется сумбурным, посмотрите для примера отношения на таблице LedgerJournalTrans

[denny]

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

[IKA]

Цитата:

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

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

• создать свой Enum, который будет отвечать за выбор этих двух таблиц. Что-то типа MyVendType::T1 и MyVendType::T2 (с осмысленными названиями, разумеется);
• добавить в таблицу T1 поле с типом MyVendType и единовременно (job-ом) заполнить это поле на основе поля vendAccount в соответствии с Вашей логикой. При этом не забыть модифицировать код, выполняемый при добавлении записей в таблицу (инициализация поля MyVendType);
• добавить к таблице T1 два отношения (relation): одно с самой собой, а второе - с таблицей T2. Эти отношения должны иметь тип связи "поле фиксировано" и строиться на поле MyVendType. (В первом случае связь будет MyVendType == 0, во втором - MyVendType == 1);
• добавить в упомянутые отношения связи по первичным ключам (однозначно идентифицирующие запись);
• на форме создать три источника данных: родительский T1 и два подчиненных: T1 и T2, и привязать их к разным TabPage, как советовал ZVV выше.

Получилось на первый взгляд громоздко, но зато: 1) не навешиваются доп. действия на linkActive (может я не прав, но имхо, нагружать этот метод - это совсем крайний случай), и 2) используется стандартный механизм динамического выбора источника данных (если это можно так назвать).

PS: если мое описание покажется сумбурным, посмотрите для примера отношения на таблице LedgerJournalTrans

Спасибо, но логика скорей там такая, что, если данные в T2 есть, то показывать данные для вендора из нее, если нет, то в тех же полях показывать данные из T1.
То есть не от конкретного знаечния вендора зависит, а от того, есть ли в T2 для него записи.

[ZVV]

Цитата:

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

Спасибо, но логика скорей там такая, что, если данные в T2 есть, то показывать данные для вендора из нее, если нет, то в тех же полях показывать данные из T1.
То есть не от конкретного знаечния вендора зависит, а от того, есть ли в T2 для него записи.

А чем вам тогда мэп поможет - не совсем понятно?

[IKA]

Цитата:

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

А чем вам тогда мэп поможет - не совсем понятно?

Смысл - скрыть от пользователя и программиста из какой таблицы берутся поля и в какую таблицу сохраняются и сделать универсальный способ работы с этими данными в системе, чтобы программисту постоянно не писать запросы, проверяющие есть ли данные в одной таблице, и если ли нету, искать в другой таблице, то же с update . Хочу всю логику инкапсулировать в мапе. Можно было бы многое сделать то же с помощью временных таблиц, возможно, но мэп позволит точней работать с полями + универсальность вызовов не зависимо от того с буфером из какой таблицы работаешь.
Какие за/против?

[ZVV]

Цитата:

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

Смысл - скрыть от пользователя и программиста из какой таблицы берутся поля и в какую таблицу сохраняются и сделать универсальный способ работы с этими данными в системе, чтобы программисту постоянно не писать запросы, проверяющие есть ли данные в одной таблице, и если ли нету, искать в другой таблице, то же с update . Хочу всю логику инкапсулировать в мапе. Можно было бы многое сделать то же с помощью временных таблиц, возможно, но мэп позволит точней работать с полями + универсальность вызовов не зависимо от того с буфером из какой таблицы работаешь.
Какие за/против?

Да я примерно понимаю для чего обычно используют мэпы...
Но это не совсем ваш случай, мне кажется... Обычно в map-е объединяют однотипные таблицы из разных модулей (типа CustVendTrans). Вы же пытаетесь объединить 2 таблицы одной и той же сущности, которые ещё и каким-то крайне странным образом зависимы ("То есть не от конкретного знаечния вендора зависит, а от того, есть ли в T2 для него записи.")
- А если нет и там, и там?
- А если в Т2 нет, но я хочу добавить?
- ...
Мне кажется Вы пытаетесь лечить последствия неправильного дизайна. Просто забыли вовремя в нужном месте добавить поле "типа записи".
И лечить лучше болезнь, если есть возможность, а не симптом...