проблема с display методом

[kitty]

Есть форма, на ней нужно сделать "накопительное поле" ну то есть в первой строке Поле = значение Field1 первой записи , во второй строке уже Поле = значение Field1 первой записи + значение Field1 второй записи и тд. Те как бы в каждой строке значение является суммой значения некоторого поля из текущей строки + из предыдущих строк над ней в гриде. Сделала, работает. Делаю то же самое в другом месте - раюотает, но странно: суммирует не с первой строки грида , а откуда-то из середины, доходит до нижней строки, а потом переходит к верхней и спускается все также накапливая сумму вниз. В дебаггере вижу. что первой строкой в Display метод передается не та строка, что верхняя самая в гриде. Решила, что дело в сортировке, сделала принудительную по RecID (для верности и конкретности). Но результате вывожу формируемый запрос - он в init и exQuery с сортировкой, на момент вызова display вывожу - тот же самый все с той же сортировкой, в грид выводятся записи тоже отсортированными по этому полю, но вот в display опять первой передается некая совершенно другая запись, причем даж не понятно почему именно она, на гриде она отображается ниже середины грида.
От чего зависит какая запись datasource-а передается в display-метод первой?
PS: Датасоурс на форме один.
PPS: Склоняюсь к тому, чтобы просчитывать значения заранее в соответствии с конкретной сортировкой, складывать значения в map, в потом в display ток выводить их, но как-то это искусственно и хотелось бы разобраться с причиной происходящего.

[mazzy]

Цитата:

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

От чего зависит какая запись datasource-а передается в display-метод первой?

От текущей сортировки.

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

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

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

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

Посмотрите как сделаны накопительные итоги в форме Сальдо по периодам, которую можно получить из плана счетов.

[kitty]

Цитата:

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

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

Цитата:

Первая запись может быть только в упорядоченной выборке (важны оба слова).

Выборку насильно упорядочиваю в init , вы хотите сказать, что не смотря на то, что в запросе стоит order by выборка все равно возвращается неупорядоченной? Почему они тогда в форме отображаются упорядоченными в соответствиии с заданной сортировкой? Грид переупорядочивается заново? Странно было б как-то ..

[miklenew]

Код посмотреть можно?

[kashperuk]

1. Я бы на RecId не завязывался - это раз. Он может иметь различные значения, и вовсе не упорядоченные.
2. Я бы добавил поле в таблицу типа Int или int64 (если записей оочень много, что врядли).
3. Сортировку сделал бы по этому полю в порядке возрастания. Создал бы соответствующий индекс (это пригодиться еще и на шаге 4), и указал бы его в свойствах источника данных.
4. Создал бы дисплей метод на уровне таблицы, который бы возвращал сумму значений всех записей таблицы, у которых значение добавленного поля меньше значения этого поля у текущей записи. (меньше или равно, в зависимости от ваших требований)
5. Метод этот скорее всего закэшировал бы (нужно уже смотреть, как работать будет в обоих случаях).
Тогда сортировка не была бы привязана к "порядку выборки".
Но при этом пользователю запрещено было бы сортировать записи по другим полям, или же фильтровать их.

[kitty]

всем спасибо
Ивану: я recid использовала, только чтоб понять в чем дело. Поля добавлять не хочу тк придется жестко закладываться на сортировку плюс(а если кой-то девелопер решит ее в форме поменять?? ) + сколько мест вызова формы столько полей как я понимаю придется и добавлять, точней даже кол-во мест * 2 (инкремент + баланс - на каждый вызов).
решила тем, что после super в exQuery формирую map а в display вывожу его результаты. Минус в отсутствии у пользователя позможности сортировки, но в вашем варианте, как я понимаю, такой же минус будет. Еще интересную вещь заметила. что если поставить infolog в display, то почему-то он вызывается 21 раз, хотя строчек в гриде 11, причем в произвольном порядке почему-то записи ds туда попадают.

[Hyper]

Формирование map при вызове executeQuery кажется оптимальным вариантом.

Цитата:

Минус в отсутствии у пользователя позможности сортировки

Неужели нет никаой формировать учитывать пользовательскую сортировку?