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

[mazzy]

Ага, а вот и логический выверт из-за которого ты так мучаешься.

Цитата:

Изначально опубликовано Andronov
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)

Дело в том, что inner join предполагает, что в M1 может быть несколько записей с одинаковым идентификатором. В этом случае запрос свяжет одну запись из D с несколькими записями из M1. И покажет все это безобразие.

Наверняка ты не это имел в виду. Но тогда запрос должен быть exist join!
А это совсем другая связь. И другие проблемы.

Ты конечно можешь сказать, что у тебя уникальность по ID. Но ЗАПРОС то об этом не знает!

В общем, если ты не хочешь писать dysplay-методы то делай в форме три грида и работай по innerJoin. Тогда не нужно вообще никакого программирования.

Если не хочешь то используй стандартное поведение tooltip. Тоже без программирования.

Или пиши display-методы и программируй.

[Andronov]

Опять таки, никого не хочу обидеть, но...
Я обычно допускаю, что могу ошибаться, поэтому нарочно поискал определения в сети:

Цитата:

Если же каждый клиент в таблице Customers может разместить ноль, один или много заказов, говорят, что эти две таблицы связаны соотношением один-ко-многим (one-to-many relationship) или соотношением master-detail. В этом случае таблица, содержащая внешний ключ, называется detail—таблицей, а таблица, содержащая первичный ключ, определяющий возможные значения внешнего ключа, называется master-таблицей.
(С) КомпьютерПресс 3'2000

Цитата:

как предполагаешь выводить конструкцию из нескольких мастеров?
например
1. планСчетов -> бухпроводки
2. клиенты -> проводки по клиентам
как такую херню показывать в отчетах, гриде?

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

Насчет каши в голове могу поспорить.

Цитата:

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

Это не связь по 2 полям. Это 2 связи, по одному полю каждая (1 - Master1ID, 2 - Master2ID) (см. рисунок)

Насчет последнего сообщения:[list=1][*]Я не знаю, может в аксапте какое-то другое понимание SQL, но приведенный запрос вполне соответствует стандарту и не подразумевает никаких неоднозначностей.[*]Оператора exist join в стандарте нет, есть inner, left outer и right outer.[*]Если я связываю 2 таблицы по внешнему ключу, я найду способ сделать так, чтоб он был уникальным. В любом случае, на запрос это никак не влияет.[/list=1]

[Wamr]

Задача. Вывести в грид поля из 2х связанных (inner) таблиц
1. Создаем форму
2. Добавляем 2 DS
3. Устанавливаем связь между DSами (JoinSource и LinkType у DS2)
4. Добавляем грид, где DataSource = DS1
5. Добавляем в грид поля из обоих DS
P.S. Такая реализация породит проблемы при вставке новой записи, но это другая история

[Andronov]

Спасибо за совет. Это очень похоже на то, что мне надо.
Только не могли бы вы объяснить, почему возникают проблемы при вставке [поле <внешний ключ> должно быть заполнено]? Ведь я вставляю запись в тот DS, который определен для грида, а там все поля заполнены.

И еще: как-то можно сделать, чтоб после выбора из списка значения внешнего ключа, соответствующие поля из DS2 обновлялись?

В любом случае, очень признателен за помощь.

[mazzy]

Цитата:

Изначально опубликовано Andronov
...поискал определения в сети:
...
Насчет каши в голове могу поспорить.

Спасибо за аргументированный ответ.
Обязательно отвечу позжде.
Постараюсь ответить аргументировано.

[Wamr]

Цитата:

Только не могли бы вы объяснить, почему возникают проблемы при вставке [поле <внешний ключ> должно быть заполнено]? Ведь я вставляю запись в тот DS, который определен для грида, а там все поля заполнены.

Точно могут сказать только разработчики Аксапты..
Видимо, при создании новой записи в DS1 ей в соответствие находится пустая запись в DS2. После изменений в DS1, происходит попытка записи всех несохраненных данных, при этом курсор в DS2 (c RecId = 0) воспринимается как новая запись и Аксапта пытается её сохранить с соответствующей ошибкой.
Обойти это можно, перекрыв пустыми методами create и write на DS2, а также validateWrite должен всегда возвращать true.

Цитата:

И еще: как-то можно сделать, чтоб после выбора из списка значения внешнего ключа, соответствующие поля из DS2 обновлялись?

СРАЗУ после выбора только с помощью display метода.
А после сохранения можно вызвать DS1.research() или executeQuery()

[Andronov]

:-))))
Я уже почти счастлив. Осталось только понять, почему если есть DS1(main), DS2(JoinSource=DS1, Inner join), DS3(JoinSource=DS1, Inner join) то все замечательно, а если к ним добавить DS4(JoinSource=DS2, Inner join), то поля, соответствующие DS3 становятся пустыми.

Огромное спасибо ВСЕМ, кто пытался помочь.

[mazzy]

Цитата:

Изначально опубликовано Andronov
поэтому нарочно поискал определения в сети:

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

Хотел показать, что типичной master-detail формой в Аксапте является заказы. Хотел продемонстрировать с картинками. Так и не нашел текст с картинками который искал.
Зато нашел кучу текста и с удовольствием читаю.

Вот что думает Microsoft на эту тему.
http://msdn.microsoft.com/library/de...formwizard.asp
Master/Detail Specifies a form that displays a Master record source and a Detail record source linked together. The Master record source is in single record format and the Detail record source is in a Grid (Datasheet) format. When data in a Master record source row changes, the data in the Detail record source automatically changes based on the link between the two.


http://msdn.microsoft.com/library/de...ndowsForms.asp

http://msdn.microsoft.com/library/de...thdatagrid.asp

http://msdn.microsoft.com/library/de...indowsform.asp


http://www.navision-us.com/us/view.asp?documentid=1106
The New Visual Design of Navision

Вот что думает Борланд
http://info.borland.com/techpubs/jbu...terdetail.html
Establishing a master-detail relationship

http://info.borland.com/techpubs/jbu...tamodules.html
http://info.borland.com/techpubs/jbu...resolving.html

А это Сан и Джавой.
http://java.sun.com/blueprints/guide...x.html#1043469

Цитата:

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

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

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

Далее.
Твой проект не соответствует диаграмме, а диаграмма не соответствует запросу.
inner join в запросе не подразумевает, что запись в клиентской таблице одна!!!
подумай над этим и многое станет понятно.

чтобы в запросе было явно сказано, что клиент один нужно делать exist join в Аксапте. В аксапте есть такой тип связи. Почитай доку.

Зарпос на T-SQL должен походить на

PHP код:

USE pubs
SELECT pub_name
FROM publishers
WHERE EXISTS
   (SELECT *
   FROM titles
   WHERE pub_id = publishers.pub_id
      AND type = 'business') 


Причем заметь одну важную штуку! В диаграмме ты указал связь 1:М, причем 1 - у тебя обязательное условие. Меньше, чем 1 запись быть не может на твоей диаграмме. При вводе новой записи в проекте, ты вполне можешь содать запись в MainTable, которая ни с чем не связана.

Цитата:

Изначально опубликовано Andronov
Если я связываю 2 таблицы по внешнему ключу, я найду способ сделать так, чтоб он был уникальным. В любом случае, на запрос это никак не влияет.

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

Постараюсь написать о лукапе и что для этого надо.
Завтра или на выходных...

Еще раз хотелось бы повторить - продумай что зачем и какие варианты имеются.
В основном твоя проблема в том, что ты ПРЕДПОЛАГАЕШЬ, что запись только одна. А Аксапта об этом ничего не знает и она работает исходя из того, что записей МОЖЕТ быть много.

[Andronov]

Я абсолютно согласен со всеми приведенными определениями. Я знаю, что master-detail форма - это когда ходишь по списку с мастерами, а в списке детейлов показываются соответствующие записи.
Тем не менее, связь master-detail - это просто связь 1:M. В связи с этим, никто не мешает показать эти данные так, как я описал.
Лукапом называется процесс выбора значения из списка. Но то, что выбираешь - это сторона "мастер", поэтому никакого противоречия здесь я не вижу.

Цитата:

Далее.
Твой проект не соответствует диаграмме, а диаграмма не соответствует запросу.
inner join в запросе не подразумевает, что запись в клиентской таблице одна!!!
подумай над этим и многое станет понятно.

Мой проект не соответствует диаграмме исключительно тем, что свойство Mandatory полей Master1ID и Master2ID не установлено в Yes. При выполнении этого условия запрос также будет верен. Связь inner join не делает никаких предположений относительно количества записей в таблицах. Все, что она определяет - это то, что в результат выборки попадут данные из обоих таблиц, причем только те, которые удовлетворяют условию связывания.

Насчет приведенного запроса: по-моему, ты попутал причину и следствие - я хотел показать РЕЗУЛЬТАТ запроса в гриде, а не подобрать такой запрос, который бы удовлетворял каким-то условиям. После множества проведенных опытов и при помощи всех (включая и тебя), высказывавших свои предложения, это в некоторой степени удалось. Кстати, написанный тобой запрос показывает данные только из таблицы publishers.

Цитата:

В основном твоя проблема в том, что ты ПРЕДПОЛАГАЕШЬ, что запись только одна. А Аксапта об этом ничего не знает и она работает исходя из того, что записей МОЖЕТ быть много.

Я не предполагаю, я это ОБЕСПЕЧУ (в Prog. guide это называется self-relating relation, что подразумевает, что данное поле - первичный ключ). Аксапта может думать что угодно, но если реально в таблице только одна строка с указанным ключем, то никаких накладок возникать не должно. Даже если таких строк несколько (это если забыть про уникальность первичного ключа), то результатом запроса будет набор, куда попадут все комбинации связанных записей из обоих таблиц.

Цитата:

Постараюсь написать о лукапе и что для этого надо.
Завтра или на выходных...

Обязательно прочитаю.
С аксаптой я только-только начинаю разбираться, поэтому буду рад любым предложениям, ссылкам, примерам и т.п.

[mazzy]

ОООО. нажал backspace вместо enter... жаль...
тогда буду краток.

Цитата:

Изначально опубликовано Andronov
Мой проект не соответствует диаграмме исключительно тем, что свойство Mandatory полей Master1ID и Master2ID не установлено в Yes.

Mandatory отвечает за обязательность ввода.
Ты не сделал уникальность, ты не указал уникальные индексы.

Цитата:

Изначально опубликовано Andronov
Связь inner join не делает никаких предположений относительно количества записей в таблицах.

Делает. inner join возвращает ВСЕ записи.
Тебе же нужна одна запись, чтобы положить ее в строку грида.
Ты должен сделать либо exist join, либо firstonly inner join.

В общем, я проект сделал. Погляди на форму myResultForm.
Обрати внимание на display метод, обрати внимание на использование типа Name.
Обрати внимание что произойдет, если в MyMaster1Table ввести несколько записей с одинаковым идентификатором. Проблема будет хорошо видна в форме myMaster2Detail_Lookup2


Теперь кратко перечислю отрицательные моменты:
Запрофилируй запросы в SQL и посмотри в какое безобразие выливается подстановка имени.
Прочитай о кэшировании таблиц. Твои мастер таблицы надо включить в кэш. Подумай.
Скорее всего, ты привык работать с 1С. Запрофилируй ее и посмотри какой ценой она делает подстановки. Открой любой документ с табличной частью. Например, счет-фактуру.
И подумай еще. Твоя мастер-таблица будет блокироваться на чтение. Тебе это надо?
Почитай best practice о формах.

Я понимаю, что 1С-овская подстановка кода или наименования удобна для пользователей. Но все имеет свою цену.

Пример 1Совского подхода и подстановки в Аксапте есть.
Попробуй поработать с контактами компании в Окружении в Персонале.
Попробуй задать список рассылки в CRM.
Это примеры того как делать не надо

Еще раз могу повторить, что Аксапта спроектирована для работы с естественными ключами. И могу еще раз дать ссылку www.mazzy.ru/axapta/hints/autonumber/

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

Да, и еще одно.
Спасибо за интересное обсуждение. Спасибо что зацепил.
Получил огромное удовольствие пока собирал материал и готовил ответ.

[Ned]

to Andronov
exist join в стандарте нет.
есть exists join

[Andronov]

To Ned: в каком стандарте? Может хоть источник какой-нить приведешь?
Я утверждаю, что такой штуки в стандарте SQL нет. По крайней мере, за несколько лет его использования, я ее ни разу не видел. Если я действительно не прав и она есть, то буду благодарен за науку. Нисколько не спорю с тем, что есть логический оператор EXISTS.

[mazzy]

Цитата:

Изначально опубликовано Ned
exist join в стандарте нет.
есть exists join

Точно. Спасибо.
Я его в очередной раз написал неправильно.