28.02.2003, 17:00 | #21 |
Участник
|
Ага, а вот и логический выверт из-за которого ты так мучаешься.
Цитата:
Изначально опубликовано 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) Наверняка ты не это имел в виду. Но тогда запрос должен быть exist join! А это совсем другая связь. И другие проблемы. Ты конечно можешь сказать, что у тебя уникальность по ID. Но ЗАПРОС то об этом не знает! В общем, если ты не хочешь писать dysplay-методы то делай в форме три грида и работай по innerJoin. Тогда не нужно вообще никакого программирования. Если не хочешь то используй стандартное поведение tooltip. Тоже без программирования. Или пиши display-методы и программируй. |
|
03.03.2003, 09:54 | #22 |
Участник
|
Опять таки, никого не хочу обидеть, но...
Я обычно допускаю, что могу ошибаться, поэтому нарочно поискал определения в сети: Цитата:
Если же каждый клиент в таблице Customers может разместить ноль, один или много заказов, говорят, что эти две таблицы связаны соотношением один-ко-многим (one-to-many relationship) или соотношением master-detail. В этом случае таблица, содержащая внешний ключ, называется detail—таблицей, а таблица, содержащая первичный ключ, определяющий возможные значения внешнего ключа, называется master-таблицей.
(С) КомпьютерПресс 3'2000 Цитата:
как предполагаешь выводить конструкцию из нескольких мастеров?
например 1. планСчетов -> бухпроводки 2. клиенты -> проводки по клиентам как такую херню показывать в отчетах, гриде? Насчет каши в голове могу поспорить. Цитата:
3. Если поставишь innerjoin, то проблем с просмотром не будет. Будут проблемы только с insert'ом. Проблемы с insert'ом только потому, что на гриде поле Master2ID ОДНО из ОДНОЙ таблицы. А связь происходит по ДВУМ полям их ДВУХ таблиц.
Насчет последнего сообщения:[list=1][*]Я не знаю, может в аксапте какое-то другое понимание SQL, но приведенный запрос вполне соответствует стандарту и не подразумевает никаких неоднозначностей.[*]Оператора exist join в стандарте нет, есть inner, left outer и right outer.[*]Если я связываю 2 таблицы по внешнему ключу, я найду способ сделать так, чтоб он был уникальным. В любом случае, на запрос это никак не влияет.[/list=1] |
|
03.03.2003, 10:39 | #23 |
----------------
|
Задача. Вывести в грид поля из 2х связанных (inner) таблиц
1. Создаем форму 2. Добавляем 2 DS 3. Устанавливаем связь между DSами (JoinSource и LinkType у DS2) 4. Добавляем грид, где DataSource = DS1 5. Добавляем в грид поля из обоих DS P.S. Такая реализация породит проблемы при вставке новой записи, но это другая история |
|
03.03.2003, 10:49 | #24 |
Участник
|
Спасибо за совет. Это очень похоже на то, что мне надо.
Только не могли бы вы объяснить, почему возникают проблемы при вставке [поле <внешний ключ> должно быть заполнено]? Ведь я вставляю запись в тот DS, который определен для грида, а там все поля заполнены. И еще: как-то можно сделать, чтоб после выбора из списка значения внешнего ключа, соответствующие поля из DS2 обновлялись? В любом случае, очень признателен за помощь. |
|
03.03.2003, 11:00 | #25 |
Участник
|
Цитата:
Изначально опубликовано Andronov
...поискал определения в сети: ... Насчет каши в голове могу поспорить. Обязательно отвечу позжде. Постараюсь ответить аргументировано. |
|
03.03.2003, 11:18 | #26 |
----------------
|
Цитата:
Только не могли бы вы объяснить, почему возникают проблемы при вставке [поле <внешний ключ> должно быть заполнено]? Ведь я вставляю запись в тот DS, который определен для грида, а там все поля заполнены.
Видимо, при создании новой записи в DS1 ей в соответствие находится пустая запись в DS2. После изменений в DS1, происходит попытка записи всех несохраненных данных, при этом курсор в DS2 (c RecId = 0) воспринимается как новая запись и Аксапта пытается её сохранить с соответствующей ошибкой. Обойти это можно, перекрыв пустыми методами create и write на DS2, а также validateWrite должен всегда возвращать true. Цитата:
И еще: как-то можно сделать, чтоб после выбора из списка значения внешнего ключа, соответствующие поля из DS2 обновлялись?
А после сохранения можно вызвать DS1.research() или executeQuery() |
|
03.03.2003, 12:42 | #27 |
Участник
|
:-))))
Я уже почти счастлив. Осталось только понять, почему если есть DS1(main), DS2(JoinSource=DS1, Inner join), DS3(JoinSource=DS1, Inner join) то все замечательно, а если к ним добавить DS4(JoinSource=DS2, Inner join), то поля, соответствующие DS3 становятся пустыми. Огромное спасибо ВСЕМ, кто пытался помочь. |
|
03.03.2003, 19:33 | #28 |
Участник
|
Цитата:
Изначально опубликовано 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 код:
Цитата:
Изначально опубликовано Andronov
Если я связываю 2 таблицы по внешнему ключу, я найду способ сделать так, чтоб он был уникальным. В любом случае, на запрос это никак не влияет. Сказать ей об этом можно только в запросе. Вот и вырази запрос так, чтобы ей было сразу понятно. Постараюсь написать о лукапе и что для этого надо. Завтра или на выходных... Еще раз хотелось бы повторить - продумай что зачем и какие варианты имеются. В основном твоя проблема в том, что ты ПРЕДПОЛАГАЕШЬ, что запись только одна. А Аксапта об этом ничего не знает и она работает исходя из того, что записей МОЖЕТ быть много. |
|
04.03.2003, 09:28 | #29 |
Участник
|
Я абсолютно согласен со всеми приведенными определениями. Я знаю, что master-detail форма - это когда ходишь по списку с мастерами, а в списке детейлов показываются соответствующие записи.
Тем не менее, связь master-detail - это просто связь 1:M. В связи с этим, никто не мешает показать эти данные так, как я описал. Лукапом называется процесс выбора значения из списка. Но то, что выбираешь - это сторона "мастер", поэтому никакого противоречия здесь я не вижу. Цитата:
Далее.
Твой проект не соответствует диаграмме, а диаграмма не соответствует запросу. inner join в запросе не подразумевает, что запись в клиентской таблице одна!!! подумай над этим и многое станет понятно. Насчет приведенного запроса: по-моему, ты попутал причину и следствие - я хотел показать РЕЗУЛЬТАТ запроса в гриде, а не подобрать такой запрос, который бы удовлетворял каким-то условиям. После множества проведенных опытов и при помощи всех (включая и тебя), высказывавших свои предложения, это в некоторой степени удалось. Кстати, написанный тобой запрос показывает данные только из таблицы publishers. Цитата:
В основном твоя проблема в том, что ты ПРЕДПОЛАГАЕШЬ, что запись только одна. А Аксапта об этом ничего не знает и она работает исходя из того, что записей МОЖЕТ быть много.
Цитата:
Постараюсь написать о лукапе и что для этого надо.
Завтра или на выходных... С аксаптой я только-только начинаю разбираться, поэтому буду рад любым предложениям, ссылкам, примерам и т.п. |
|
04.03.2003, 21:04 | #30 |
Участник
|
ОООО. нажал backspace вместо enter... жаль...
тогда буду краток. Цитата:
Изначально опубликовано Andronov
Мой проект не соответствует диаграмме исключительно тем, что свойство Mandatory полей Master1ID и Master2ID не установлено в Yes. Ты не сделал уникальность, ты не указал уникальные индексы. Цитата:
Изначально опубликовано Andronov
Связь 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/ На этом форуме эта тема обсуждалась уже неоднократно. Обязательно поищи. Там еще много чего народ приводил в качестве плюсов и минусов. К сожалению, я нечаянно стер предыдущий вариант ответа со ссылками на топики... Да, и еще одно. Спасибо за интересное обсуждение. Спасибо что зацепил. Получил огромное удовольствие пока собирал материал и готовил ответ. |
|
05.03.2003, 12:13 | #31 |
Lean Six Sigma
|
to Andronov
exist join в стандарте нет. есть exists join |
|
05.03.2003, 12:29 | #32 |
Участник
|
To Ned: в каком стандарте? Может хоть источник какой-нить приведешь?
Я утверждаю, что такой штуки в стандарте SQL нет. По крайней мере, за несколько лет его использования, я ее ни разу не видел. Если я действительно не прав и она есть, то буду благодарен за науку. Нисколько не спорю с тем, что есть логический оператор EXISTS. |
|
06.03.2003, 15:24 | #33 |
Участник
|
Цитата:
Изначально опубликовано Ned
exist join в стандарте нет. есть exists join Я его в очередной раз написал неправильно. |
|