Очень простые (как мне думается) вопросы по реализации лукапа

[Andronov]

1. Можно ли лукапить не по тому полю, через которое таблицы связаны (в идеале, вообще его не показывать)

2. Как сделать, чтоб в гриде отображались поля выбранного мастера.
Сейчас я делаю так: в DataSources формы добавил 2 таблицы (скажем, Libraries и ReaderCards). Свойство DataSource грида установил в ReaderCards. На грид перетащил нужные поля из обоих DataSource'ов. Возникает ощущение, что поля, соответствующие таблице Libraries, живут в этом гриде своей собственной жизнью и никак не связаны с тем, что я выбрал при лукапе.

[Андре]

Цитата:

1. Можно ли лукапить не по тому полю, через которое таблицы связаны (в идеале, вообще его не показывать)

Это как ? В главную таблицу из detail-таблицы будет все равно подставляться то поле, по которому эти таблицы связаны.


Насчет пункта 2 - а ты датасоурсы связал ? Свойства - JoinSource и LinkType

[Andronov]

Пункт 1 связан с пунктом 2.
Я хочу на форме, скажем, читательского билета показывать в списке ЧитБилетов Название библиотеки и Фамилию, Имя, Отчество читателя, соответствующие билетам. При этом привязывать таблицы Библиотека и Читатель к ЧитатательскомуБилету хочу через поля LibraryID и ReaderID. Очевидно, что показывать значения этих полей - первичных ключей Библиотеки и Читателя - пользователю незачем.

Итак, вопросы:
1. Как показать атрибуты соответствующих Читателя и Библиотеки в списке Чит.билетов

2. Если это можно сделать, то как лукапить Читателя не из поля ReaderID, а, например, из поля его фамилии. Понятно, что при этом хотелось бы, чтоб в ReaderID подставлялось соответствующее значение.

[Андре]

Во-первых посмотри форму tutorial_join.

Цитата:

Очевидно, что показывать значения этих полей - первичных ключей Библиотеки и Читателя - пользователю незачем.

Просто не выносите эти поля на Grid.

Цитата:

2. Если это можно сделать, то как лукапить Читателя не из поля ReaderID, а, например, из поля его фамилии. Понятно, что при этом хотелось бы, чтоб в ReaderID подставлялось соответствующее значение.

Уточните, что вы понимаете под термином "лукапить". Это ниспадающий грид, который выпадает при кликании на стрелку при выборе какого-либо значения из справочника ?
Если да, то:

1. У таблицы есть такая группа полей, как AutoLookup - поместите в нее те поля, которые вы хотите видеть при LookUp'е
2. Если нужно что-то более сложное, можно оздать свою лукапную форму.

[Andronov]

Цитата:

Уточните, что вы понимаете под термином "лукапить". Это ниспадающий грид, который выпадает при кликании на стрелку при выборе какого-либо значения из справочника ?

Именно! Я хочу, чтоб стрелка появлялась не только на том поле, через которое я связываю таблицы (его я вообще показывать не хочу), а на поле, в котором показываются данные не из текущей таблицы, а из связанной. Я уже не знаю, какой пример придумать. Ну, пусть в списке городов показывается для каждого города, к какой области он относится. Пусть показывается полное наименование области, а связь города с областью происходит через какое-то другое поле.

Цитата:

Во-первых посмотри форму tutorial_join.

Да смотрел я. Уже куда только не смотрел.

Цитата:

Просто не выносите эти поля на Grid.

Тогда стрелки нет. Выбирать не дает.

Цитата:

1. У таблицы есть такая группа полей, как AutoLookup - поместите в нее те поля, которые вы хотите видеть при LookUp'е
2. Если нужно что-то более сложное, можно оздать свою лукапную форму. [/B]

Это все понятно. Как мне в том списке, где на стрелку нажимаю, показать поля того, что показывается в выпадающем списке?

Вроде, такая штука простая, должна быть. Ну ведь есть же? А?

[Dron AKA andy]

В качестве примера можно посмотреть форму "Клиенты" lookup по контактному лицу на закладке "Контакты". Там похожая вещь реализована.

[mazzy]

А также посмотрите на Network (Окружение) HRMVirtualNetworkTable
и посмотрите как это используется. Например, действиях в модуле "управление бизнес-процессами" или как задаются группы рассылки.

Попробуйте сделать поиск, фильтр, распечатать и сделать прочие базовые вещи.

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

Сделать форму - мало. Нужно чтобы работал весь функционал. Ну или хотя бы большинство из стандартного функционала. Жертвовать фильтрами ради удобной для программиста концепции искусственных ключей - ИХМО перебор.

К тому же искусстевенные ключи - это дополнительная нагрузка на сервер.

[Garic]

Цитата:

А также посмотрите на Network (Окружение) HRMVirtualNetworkTable

А также обратите внимание на кривизну написанного. Не знаю как у вас, а у нас все номерные серии содержат буквы - соответственно этот код не работает.

PHP код:

        hrmVirtualNetworkIdTmp = strKeep(hrmVirtualNetworkId,"0123456789");
        if (hrmVirtualNetworkIdTmp != hrmVirtualNetworkId)
        {
            warning("@GLS664");
        }
        else
            common.(fieldId) = hrmVirtualNetworkId; 


[Andronov]

Блин, может я плохо объясняю...
Откройте форму Закупки в раширенном режиме.
При добавлении строки в поле "номенклатура" выбираем код номенклатуры и после этого поле "название номенклатуры" заполняется автоматически соответствующим значением. Так вот, это поле в этой форме привязано к методу таблицы PurchLine.itemName(). IMHO, писать такую штуку для каждого нужного поля - не самое разумное дело. Кроме того, выбрать номенклатуру, ткнув куда-нить в поле "название номенклатуры" нельзя.

Неужели в аксапте нет средств для того, чтоб показать нужные поля из связанной таблицы без написания методов типа PurchLine.itemName()?

Цитата:

К тому же искусстевенные ключи - это дополнительная нагрузка на сервер.

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

[kalex]

Можно перекрыть метод Lookup на поле Grid-а и делать в нём, что душе угодно. :-)

[Dron AKA andy]

to Andronov: еще раз рекомендую взглянуть на форму "Клиенты", закладка "Контакты", lookup по полю "Контактное лицо". Там как раз выводится имя контактного лица, хотя в табл. клиентов, естественно, хранится код. При выборе в лукапе этот код не показывается.

[Ned]

1.В таблице - сделать дата метод.
2.У контрола - переписать лукап. Например:
SysTableLookup sysTableLookup = SysTableLookup::newParameters(tableNum(InventLocationGroupTable), this);
Query query = New Query();
QueryBuildDataSource queryBuildDataSource = query.addDataSource(tableNum(InventLocationGroupTable));
;

queryBuildDataSource.addRange(fieldNum(InventLocationGroupTable, InventLocationGroupId)).value(
InventLocationGroup.text());
sysTableLookup.addLookupfield(fieldNum(InventLocationGroupTable, InventLocationId));
sysTableLookup.addLookupfield(fieldNum(InventLocationGroupTable, InventLocationGroupId));
sysTableLookup.parmQuery(query);
sysTableLookup.performFormLookup();

[mazzy]

Цитата:

Изначально опубликовано Garic
А также обратите внимание на кривизну написанного. Не знаю как у вас, а у нас все номерные серии содержат буквы - соответственно этот код не работает.

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

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

Аксапта исповедует вот этот подход http://www.mazzy.ru/axapta/hints/autonumber/index.html
Искусственные ключи в Аксапте - это борьба с ветряными мельницами, ИХМО.

Но буду с громадным интересом наблюдать за любопытными и дерзкими. В конце-концов первые летательные аппараты тоже только падали

[Andronov]

Всем большое спасибо за советы.
To Mazzy: спасибо, сайт понравился.

Возник такой вопрос: можно ли в одном гриде показывать данные из нескольких таблиц? Также, как результат join в SQL.

[mazzy]

Хм... Андре говорил, что стоит посмотреть tutorial_join
http://www.axforum.info/forums/showt...=8859#post8859

Чем эта форма не понравилась? Почему вопрос возник повторно?

[Andronov]

Вопрос возник повторно, потому что в примере tutorial_join есть 2 вещи, которые мне надо изменить:
1. Я хочу, чтоб мастеров было не 1, а хотя бы 2.
2. Я хочу, чтоб DataSource'ом грида был не мастер, а детейл, а поля мастеров показывались в гриде.

Все предельно просто: я хочу, чтоб в гриде был аналог результата запроса:
select D.*, M1.SomeField, M2.SomeField
from
Detail D inner join
Master1 M1 on (D.M1 = M1.ID) inner join
Master2 M2 on (D.M2 = M2.ID)

При этом у меня нет желания писать методы в таблице Detail, которые бы находили по ключу соответствующие значения в таблицах MasterX типа:

PHP код:

 return InventTable::find(this.itemId).itemName(this.configId); 


[mazzy]

Хм... мастер-таблица может быть только одна. ПО ОПРЕДЕЛЕНИЮ.
их не может быть две или больше. ПО ОПРЕДЕЛЕНИЮ.

У тебя есть три понятия:
1. датасорсы (мастер-детейл)
2. таблица-источник грида
3. таблица-источник поля

Вот и комбинируй эти понятия как тебе нужно.
Если ты хочешь, чтобы датасорсом грида был детайл - укажи.
если тебе не нравится порядок вывода - выверни мастер-детайл (все равно у тебя inner)

Я в упор не могу понять в чем твои проблемы.

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

Тут уж либо следи за стандартной логикой, либо разрабатывай новую форму.
У тебя есть другие предложения?

[Andronov]

Откуда определения?

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

Цитата:

Вот и комбинируй эти понятия как тебе нужно.
Если ты хочешь, чтобы датасорсом грида был детайл - укажи.
если тебе не нравится порядок вывода - выверни мастер-детайл (все равно у тебя inner)

Рекомендую попробовать изменить DataSource грида в tutorial_join на TmpJoinDetail и походить по последнему столбцу.

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

Или посмотреть в мой ОЧЕНЬ простой пример (приаттачен) и пояснить, почему, если я указал мастеровому DataSource'у JoinSource=детейловая таблица и вытянул поле мастера в грид, для которого указал DataSource = детейловая таблица, то нужные значения в этом поле показываются только тогда, когда я встаю на него курсором.

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

[mazzy]

посмотрю.

про определения... пусть будет по твоему.
как предполагаешь выводить конструкцию из нескольких мастеров?

например
1. планСчетов -> бухпроводки
2. клиенты -> проводки по клиентам

как такую херню показывать в отчетах, гриде?

[mazzy]

1. Такое ощущение, что у тебя каша в голове
1.1. то что у тебя названо mainTable это и есть мастер таблица в форме
1.2. то что у тебя названо мастер-таблицами обычно называется подчиненными (detail) таблицами

2. ты невнимательно посмотрел в tutorial_join
2.1 во-первых, там innerjoin, а не delayed
2.2 во-вторых, там неспроста стоят initValue

3. Если поставишь innerjoin, то проблем с просмотром не будет. Будут проблемы только с insert'ом. Проблемы с insert'ом только потому, что на гриде поле Master2ID ОДНО из ОДНОЙ таблицы. А связь происходит по ДВУМ полям их ДВУХ таблиц.

Т.е. тебе нужно обеспечить, чтобы при изменении поля Master2ID в mainTable автоматически изменялось поле в подчиненной таблице (поле, которое не показывается в гриде) и после изменения ты должен сказать Аксапте, что она должна пересвязать таблицы. В примере это объодится за счет initValue.

Будь внимателен с tutotial

Насчет выворотки. Если уж выворачиваешь логику, то перепрограммировать приходится многое. Перекинуть связь в свойствах датасорса достаточно только в простейших случаях. Именно такие случаи и рекомендует нам для использования best practice.

В общем, ты точно уверен, что хочешь этим заниматься?
Тогда прочитай последовательность обработки событий. Руководство разработчика, ключевое слово sequence. Прочитай best practice по поводу создания и работы форм.