Сумма нарастающим итогом в DBGrid

← →
Леонид (2002-04-24 11:34) [0]

DBGrid c 2-я колонками. В первую заносятся числа. Необходимо, стобы после завершения ввода в ячейку в каждой ячейке 2-й колонки появилась сумма ячеек 1-й нарастающим итогом.

← →
Praco (2002-04-24 11:52) [1]

А что за база?

← →
Леонид (2002-04-24 12:08) [2]

DBF-файлы

← →
SONY (2002-04-24 12:39) [3]

поле f2 делаешь вычисляемым
на обработке OnCalcfield
сначала делаешь запрос (TQuery)
select sum(f1) from table1
и пишеш DataSet.FieldByNAme(f2).Value := FieldByNAme(f2).Value+Query1["SUM"]

← →
Sergey13 (2002-04-25 09:36) [4]

2Леонид (24.04.02 11:34)
А нарастающий итог нужен по всей таблице или по произвольной выборке?
2SONY (24.04.02 12:39)
При этом методе, учитывая количество записей и частоту вызова обработчика OnCalcfield ИМХО долго придется ждать результатов.

← →
Johnmen (2002-04-25 09:43) [5]

>Леонид : Ты скажи конкретно, зачем это надо по жизни, а такие решения - это полный изврат...да к тому же еще и не работающий...

← →
Praco (2002-04-25 09:52) [6]

> SONY (24.04.02 12:39)
Sergey13 © (25.04.02 09:36) прав, SQL для DBF будет работать медленно. Проще завести переменную (поле) и в ней накапливать нарастающий итог.

IncSum := IncSum + DataSet.FieldByNAme("f1").Value;
DataSet.FieldByNAme("f2").Value := IncSum;

> All
Чисто на SQL проблема по-моему не решается. Или как?

← →
Johnmen (2002-04-25 09:59) [7]

>Praco © : Где же будет выполняться приведенный код ? :)

← →
Lusha (2002-04-25 10:02) [8]

>Praco © (25.04.02 09:52)
Тогда уж не переменную, а массив (причем динамический. Читай TList)... Массив записей типа...

TSubtotal = record
Bookmark : TBookmarkStr; // Индекс записи
Value : double; // Собственно значение
end;

← →
Sergey13 (2002-04-25 10:16) [9]

ИМХО можно сделать так. Добавить статическое (sum_stat например) поле в таблицу, в которое писать значение как новое введенное+предыдущее sum_stat. При выборке читать значение sum_stat у первой записи в переменную. И в созданом вычисляемом поле (sum_calc например) вычитать из текущего sum_stat значение переменной. На первый взгляд должно работать побыстее.

← →
Johnmen (2002-04-25 10:20) [10]

>Sergey13 © : Поясняю, что таки макаром, через вычисляемое поле, ничего не получится ! Кроме полного бреда !

← →
Sergey13 (2002-04-25 10:41) [11]

2Johnmen © (25.04.02 10:20)
Почему?

← →
Johnmen (2002-04-25 10:51) [12]

>Sergey13 © : Потому, что вызов процедуры вычисления поля OnCalcField происходит каждый раз при обращении к записи, для которой необходимо вычислить значение калк.поля, например при отрисовке значения к.поля в гриде.

← →
Sergey13 (2002-04-25 11:07) [13]

2Johnmen © (25.04.02 10:51)
Все правильно. Именно поэтому у меня и возникли сомнения по поводу высказывания SONY (24.04.02 12:39). Но в моем варианте в вычисляемом поле будет просто из значения в статическом поле вычитаться какое-то число. Для чистоты эксперимента можно это чисто получать не как первое из текущей выборки, а из отдельной выборки возвращающей одну запись. Ты наверное не внимательно прочитал мой пост Sergey13 © (25.04.02 10:16), или я не понятно объяснил идею. Основная мысль была в добавлении нового поля (не вычисляемого а реального ) в таблицу. А если в вычисляемом поле нельзя показывать разницу другого (статического) поля и какой то постоянной (для данной выборки) величины, то тогда что вообще в нем можно?

← →
Johnmen (2002-04-25 11:16) [14]

>Sergey13 ©
>...Добавить статическое (sum_stat например) поле в таблицу, в
>которое писать значение как новое введенное+ sum_stat.

В том-то и проблема, что нет критерия "предыдущее" !!!

← →
Sergey13 (2002-04-25 11:25) [15]

2Johnmen © (25.04.02 11:16)
>В том-то и проблема, что нет критерия "предыдущее" !!!
Почему нет? Это же не в OnCalcField надо а просто при вставке новой строки. Что нельзя прочитать предыдущую запись из выборки?

← →
Fareader (2002-04-25 11:29) [16]

>Johnmen © В том-то и проблема, что нет критерия "предыдущее"
если ты имеешь в виду предыдущее значение поля то это не совсем так, можно в событии BeforePost получить NewValue и OldValue.

← →
Johnmen (2002-04-25 11:32) [17]

>Sergey13 © Можно прочитать текущую запись из выборки, но это вовсе не значит, что она является предыдущей применительно к описанию "предыдущая" !

← →
Sergey13 (2002-04-25 11:39) [18]

2Johnmen © (25.04.02 11:32)
Че то мы друг друга не понимаем.
Тут надо разбираться с условиями задачи.
Ау-у-у Леонид!!!

← →
Johnmen (2002-04-25 11:42) [19]

>Fareader ©

1. Я ничего не имею в виду под "предыдущее", это не ко мне.
2. Имелось в виду совсем другое... :)

← →
Lusha (2002-04-25 11:49) [20]

>Fareader © (25.04.02 11:29)
Про CachedUpdates тут речь не идет вовсе...

>Sergey13 © (25.04.02 11:25)
Согласитесь, что хранить вычисляемые данные (к тому же не несущие абсолютно никакой полезной информации) некорректно по определению... Что касается предложенного Вами варианта, то он будет работать лишь при наличии двух НД, а это опять таки проблемы с быстродействием...

>Леонид (24.04.02 12:08)
Постановка задачи корявая (и это мягко сказано). В принципе подобные задачи не должны возникать вообще...

← →
Johnmen (2002-04-25 11:51) [21]

Используя только лишь НД и всевозможные приемы работы с ним никакая задача типа "нарастающий итог" не может быть решена...

И повторюсь :
>Леонид : Ты скажи конкретно, зачем это надо по жизни

← →
Fareader (2002-04-25 11:52) [22]

Я чего-то в этой ветке совсем запутался, автор вопроса может еще раз толково пояснить что ему нужно.

← →
Sergey13 (2002-04-26 09:42) [23]

Вчера не успел, инет отрубили 8-(

2Lusha © (25.04.02 11:49)
>Согласитесь, что хранить вычисляемые данные (к тому же не >несущие абсолютно никакой полезной информации) некорректно по >определению...
По определению чего? 3 нормальной формы. Так это не закон и не догма, а метод оптимизации. Для ежедневного получения справок по зарплате работников за несколько лет, вы что собираетесь каждый раз считать ее (зарплату)? И для этого хранить тонны информации по больничным, тарифам, переработкам и т.д. и т.п.... Или все же проще один раз посчитать и результат сохранить в итоговой таблице.

>Что касается предложенного Вами варианта, то он будет работать >лишь при наличии двух НД, а это опять таки проблемы с >быстродействием...
Возможно и с 1НД, но возможно возникнут некоторые трудности. С двумя НД действительно проще и понятнее. Насчет быстродействия -иногда 10 НД обработаются быстрее 1. Тут важно что за НД.

2Johnmen © (25.04.02 11:32)
Я кажется въехал в наши разногласия. Мой метод действительно будет работать корректно только на добавление записей в конец в выборках типа "показать последние за...". То есть для системы с четкой неизменяемой хронологией. При вставке строки не в конец, или при модификации поля метод работать не будет. Тут надо голову ломать. Проще будет такую информацию (по нарастающему итогу) выводить не в гриде, а в отдельном Edite для текущей записи. Иначе накладные расходы "сожрут" все удобство.

← →
Johnmen (2002-04-26 09:53) [24]

>Sergey13 © :
1. это типа 1С-шный вариант, он имеет существенные недостатки, какие - я думаю понятно... :)
2. с одним НД и только с ним - не получится...
3. аналогичная идея уже высказана Lusha © (25.04.02 10:02).

← →
Lusha (2002-04-26 10:16) [25]

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

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

Проще будет такую информацию (по нарастающему итогу) выводить не в гриде...
Какая разница где выводить? Вопрос - ОТКУДА БРАТЬ?

Я кажется въехал в наши разногласия. Мой метод действительно будет работать корректно только на добавление записей в конец...
Ничего то Вы не поняли... По большому счету Ваш метод не будет работать и с двумя НД... Достаточно предположить количество пользователей в системе более одного...

← →
Kouzmine (2002-04-26 10:40) [26]

Я так понял, что нарастающий итог нужен по каждому человеку в отдельно. Если это так, то имеется главная таблица и подчиненная. Тогда, на смену записи в главной, сделать так в подчиненной. (Дополнительное поле необходимо)
var
Sum : Double;

Sum := 0;
X.Edit;
Sum := X.FieldByName("A").Value //Самая первая сумма
X.FieldByName("Y").Value := Sum;
X.Post;
while not X.Eof do
begin
Sum := Sum + X.FieldByName("A").Value
X.Edit;
X.FieldByName("Y").Value := Sum;
X.Post;
X.Next;
end;

По моему опыту, количество записей для обсчета не превышают за год 20-30. Работать должно почти мгновенно.

← →
Sergey13 (2002-04-26 10:45) [27]

2Lusha © (26.04.02 10:16)
>Именно... А иначе придется хранить тонны бумаги, чтобы иметь >возможность восстановить причину появления той или иной цифры...
Ню-ню...

>Какая разница где выводить? Вопрос - ОТКУДА БРАТЬ?
Просто при таком подходе можно обрабатывать запрос типа
select sum(field1) from table where id<:id_current. Получится намного быстрей и проще.

>Ничего то Вы не поняли... По большому счету Ваш метод не будет >работать и с двумя НД... Достаточно предположить количество >пользователей в системе более одного...
Интересно как это повлияет на работоспособность метода (с учетом оговорок Sergey13 © (26.04.02 09:42))

← →
Lusha (2002-04-26 10:50) [28]

Просто при таком подходе можно обрабатывать запрос типа
select sum(field1) from table where id<:id_current. Получится намного быстрей и проще...
Быстро, просто, но неправильно. Второй пользователь тоже не дремлет... :)

Интересно как это повлияет на работоспособность метода (с учетом оговорок Sergey13 © (26.04.02 09:42))...
Катастрофически...

← →
Johnmen (2002-04-26 10:51) [29]

>Kouzmine © : Ты не совсем осознаешь, что может скрываться за X в твоем примере, и того факта, что в его НД никак не учитывается порядок !

← →
Kouzmine (2002-04-26 11:04) [30]

Срать на порядок. Будет пересчитываться в текущем порядке.

← →
Kouzmine (2002-04-26 11:07) [31]

А Х может быть что угодно. Это вообще не важно. Единственное, что для прядка надо сделать X.First;

← →
Sergey13 (2002-04-26 11:13) [32]

2Lusha © (26.04.02 10:50)
>Быстро, просто, но неправильно. Второй пользователь тоже не дремлет... :)
Ну по этой логике с БД вообще нельзя работать больше чем одному пользователю (больше двух не собираться!!!8=). Такой запрос вернет ПРАВИЛЬНОЕ значение на ТЕКУЩИЙ момент времени.

>Катастрофически...
Голословно...

← →
Kouzmine (2002-04-26 11:18) [33]

Ребята. Все это фигня. Справки для одного человека двадцать бухгалтеров делать не будут по простой причине, что эти справки выдаются по требованию. И только дебил будет просить их сделать у всех имеющихся бухгалтеров, тем более одновременно. А так пересчет идет не по всей базе, а подчиненных записях, только!!!!! одного человека.

← →
Johnmen (2002-04-26 11:23) [34]

← →
Sergey13 (2002-04-26 11:24) [35]

← →
Kouzmine (2002-04-26 11:28) [36]

Johnmen`у. Это наложенный индекс. Или по порядку записей. И вообще - это тоже не важно.

← →
Johnmen (2002-04-26 11:41) [37]

>Kouzmine © (26.04.02 11:28)
К сожалению, у тебя нет глубокого понимания таких вещей как "порядок","индекс" и т.п. -
отсюда высказывания, типа "... по порядку записей...", " И вообще - это тоже не важно."

PS Без обид...

← →
Lusha (2002-04-26 11:45) [38]

>Sergey13 © (26.04.02 11:24)
Гы-гы. Я вообще то тоже об SQL...

>Sergey13 © (26.04.02 11:13)
Такой запрос вернет ПРАВИЛЬНОЕ значение на ТЕКУЩИЙ момент времени
Вот именно. А набор данных отображаемый в гриде на какой момент времени сформирован? А что произошло за это время? Что другой пользователь не мог записей добавить? Мог конечно. А у нас, извините, определение значения CalcField на любое перемещение по НД и его модификации...
... и в итоге нам этот запрос такое возвратит, что пользователь за голову возьмется... Добавил запись с суммой 10, а нарастающий итог увеличился на 100... :)

Голословно...
А я не думаю, что мое утверждение требует доказательств...

>Леонид
Что молчите то? Уже отлегло... Больше не хочется? :)

>Kouzmine © (26.04.02 11:18)
Какие справки... Прочитайте ветку внимательно с самого начала...

← →
Kouzmine (2002-04-26 11:46) [39]

Johnmen`у - возьми книжку и почитай. Когда поймешь, тогда будешь давать советы другим. Без обид.

← →
Johnmen (2002-04-26 11:51) [40]

>Kouzmine © (26.04.02 11:46)
В твоем возрасте уже пора быть повежливей и не приводить детских аргументов вроде "сам дурак"....

← →
Kouzmine (2002-04-26 11:53) [41]

Лаше. Цитирую. "Для ежедневного получения справок по зарплате работников за несколько лет, вы что собираетесь каждый раз считать ее (зарплату)?
Не надо передергивать на счет ежедневного... :)"
Помни о чем пишешь.

← →
Sergey13 (2002-04-26 11:55) [42]

2Lusha © (26.04.02 11:45)
>Гы-гы. Я вообще то тоже об SQL...
Под SQL я понимал SQL-сервер.

>Вот именно. А набор данных отображаемый в гриде на какой момент >времени сформирован? А что произошло за это время? Что другой >пользователь не мог записей добавить? Мог конечно. А у нас, >извините, определение значения CalcField на любое перемещение >по НД и его модификации...
>... и в итоге нам этот запрос такое возвратит, что пользователь >за голову возьмется... Добавил запись с суммой 10, а >нарастающий итог увеличился на 100... :)
Почему? Ведь я предлагаю вычислять поле по уже закачаному набору. Поле минус значение этого поля в первой записи. Никакого дополнительного обращению к серверу (которого оказывается нет 8-) не будет.

Все скоро 12.00 Щас инет отрубят. До понедельника. Если получится.

← →
Kouzmine (2002-04-26 12:08) [43]

При чем тут SQL сервер? Файлы DBF. Не надо золотить контакты на лампочке в туалете. Легче будет жить.

Сумма нарастающим итогом в DBGrid Найти похожие ветки