Засада с позиционированием при переходе к основной таблице. В чем дело?

[AK9]

Всем привет
Подскажите с такой ситуацией.

Необходимо сделать в форме закупок сортировку по умолчанию не по номеру закупки, а по дате прихода. Сделал новый индекс DeliveryDateIdx в таблице PurchTable, выставил в форме закупок сортировку по этому индексу, все ок. Но при переходе из поля "Закупка" журнала отборочных накладных по меню "Перейти к основной таблице" открывается не та запись в форме закупок.

Прочитал, что для того, чтобы открывалась нужная запись нужно в рилэйшнз таблицы добавить еще один. Создаю в таблице PurchTable рилэйшены PurchTable.PurchId == PurchTable.PurchId и PurchTable.DeliveryDate == PurchTable.DeliveryDate, но все остается как прежде

Что я делаю не так?
Можно, конечно, перегрузить jumpRef в журнале ОН, но закупки много из каких форм вызываются, все замучаешься перегружать...

Axapta 3.0 SP4

[konopello]

Цитата:

Сделал новый индекс DeliveryDateIdx в таблице PurchTable, выставил в форме закупок сортировку по этому индексу, все ок. Но при переходе из поля "Закупка" журнала отборочных накладных по меню "Перейти к основной таблице" открывается не та запись в форме закупок.

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

[AK9]

да, работало нормально.
дело не в запросе, а в том, что я, похоже, не так рилэйшны выставляю, а вот как их правильно поставить, чего-то недопру. Вроде делаю как написано здесь http://erpkb.com/Axapta/PerexodKOsnovnojjTablice

[belugin]

собственно оно так и есть. Насколько я помню AndyD разьяснял, что происходит просмостр записей в порядке индекса. Мне кажется, стоит обрабатывать на вызываемой форме - если заполнен args.lookupField то менять сортировку на обычную

[belugin]

Упс. Переситал свою же страницу - понял. В принципе, проблема в том, что отношения на таблице не перебивают, насколько я понял отношения на EDT (но я щас не уверен, надо пожкспериментировать) попробуйте сделать свой EDT без отношений а не использовать PurchID

[AK9]

Цитата:

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

попробуйте сделать свой EDT без отношений а не использовать PurchID

Сделал, результат прежний...

[belugin]

можете показать query.xml() в вызываемой таблице и посмотреть, какие дайналинки там есть? Происходит фильтрация или позиционирование?

[AK9]

ммм, честно говоря не совсем понял о чем идет речь, вы это имеете в виду?

<Query Name="" Title="" Form="SysQueryForm" UserUpdate="Yes" Version="4" Literals="Default" Interactive="Yes" AllowCheck="Yes" RecordLevelSecurity="Yes" NextUniqueId="1001" >
  <methods />
  <Data_Sources>
    <datasource Name="PurchTable" Table="PurchTable" UniqueId="1000" Company="" FirstOnly="No" FirstFast="Yes" AllowAdd="All_fields" OrderMode="Order_by" FetchMode="1:n" JoinMode="InnerJoin" Update="No" Relations="No" Enabled="Yes" >
      <fieldlist Dynamic="Yes" >
      </fieldlist>
      <order>
        <DeliveryDateIdx>
        </DeliveryDateIdx>
      </order>
      <Ranges>
      </Ranges>
      <Data_Sources>
      </Data_Sources>
    </datasource>
  </Data_Sources>
</Query>

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

[kashperuk]

Таки Максим правильно написал в первом сообщении
При переходе к основной таблице делается запрос вида >= Значение поля PurchId
И если записи отсортированы не по этому полю, то переход к основной таблице пойдет лесом.
Дело в том, как выполняется поиск этой записи - как только АХ натыкается на значение МЕНЬШЕ чем Значение поля PurchId, она думает, что уже все - дальше искать смысла нет. Что при использовании другой сортировки может быть неправдой

[kashperuk]

А Relation тут вроде как вообще не при чем.
Он используется для диналинков, а переход к основной таблице использует другой подход

[AK9]

хм, ну я исходил из вышеуказанной статьи http://erpkb.com/Axapta/PerexodKOsnovnojjTablice
а про то, что условие позиционирования будет по типу >= purchId я читал. Вот вроде как эту то проблему рилэйшны и должны решить, как я понял из статьи.

[AK9]

"Следует учесть, что позиционирование работает не правильно, если порядок сортировки в форме на которую осуществляется переход не начинается с ключевого поля. В этом случае надо добавить в отношение второе поля, чтобы осуществлялась фильтрация. (пример можно найди в Таблица / Vend Invoice Jour — там задано отношение Vend Invoice Jour? из нескольких полей и при переходе к основной таблице на поле «Номер накладной» происходит фильтрация формы перехода)"

Ну вот я и добавил в отношения две записи:
PurchTable.PurchId == PurchTable.PurchId
PurchTable.DeliveryDate == PurchTable.DeliveryDate

[belugin]

Проблема в том, что не происходит фильтрация (показывается больше 1 записи) или в том, что фильтрует неправильно?

[AK9]

происходит следующее. например есть, например, закупки ЗК123 с датой прихода 13.11.2007 и ЗК124 тоже с датой прихода 12.11.2007. Если в журнале отборочных накладных встать на накладную по ЗК123, и из поля "Закупка" перейти к основной таблице, то получим форму закупок, с курсором, стоящим на ЗК124.

[AK9]

Происходит так потому, что сортировка в форме стоит по дате прихода, а при

Цитата:

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

При переходе к основной таблице делается запрос вида >= Значение поля PurchId

получается при переборе первой записью со значением purchId >= ЗК123 мы находим ЗК124, так как дата прихода у нее раньше.

[belugin]

так релейшены ты настроил на PurchTable или на журнале отборочных накладных?

Вот это будет работать только при переходе с PurchTable на PurchTable
PurchTable.PurchId == PurchTable.PurchId и PurchTable.DeliveryDate == PurchTable.DeliveryDate

[AK9]

да я уже и там, и там пробовал... вроде должно работать, ан нет

[belugin]

Чек лист:
1. Убедитесь, что на таблице, с которой вы переходите есть relation c двумя полями на PurchTable
2. Убедитесь что на таблице, с которой вы переходите, отсутствуют поля, EDT которых имеют relation на PurchTable. И у предков EDT до седьмого колена
3. Наугад: попробуйте перестроить перекрестные ссылки по структуре данных

Проверка:

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