Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: 1 2 3 >
Леонид © (2002-04-24 11:34:00)
DBGrid c 2-я колонками. В первую заносятся числа. Необходимо, стобы после завершения ввода в ячейку в каждой ячейке 2-й колонки появилась сумма ячеек 1-й нарастающим итогом.

Kouzmine (2002-04-26 12:08:00) [1]
При чем тут SQL сервер? Файлы DBF. Не надо золотить контакты на лампочке в туалете. Легче будет жить.

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

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

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

Kouzmine (2002-04-26 11:53:00) [3]
Лаше. Цитирую. "Для ежедневного получения справок по зарплате работников за несколько лет, вы что собираетесь каждый раз считать ее (зарплату)?
Не надо передергивать на счет ежедневного... :)"
Помни о чем пишешь.

Johnmen (2002-04-26 11:51:00) [4]
>Kouzmine © (26.04.02 11:46)
В твоем возрасте уже пора быть повежливей и не приводить детских аргументов вроде "сам дурак"....

Kouzmine (2002-04-26 11:46:00) [5]
Johnmen`у - возьми книжку и почитай. Когда поймешь, тогда будешь давать советы другим. Без обид.

Lusha (2002-04-26 11:45:00) [6]
>Sergey13 © (26.04.02 11:24)
Гы-гы. Я вообще то тоже об SQL...

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

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

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

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

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

PS Без обид...

Kouzmine (2002-04-26 11:28:00) [8]
Johnmen`у. Это наложенный индекс. Или по порядку записей. И вообще - это тоже не важно.

Sergey13 (2002-04-26 11:24:00) [9]
2Lusha © (26.04.02 10:50)
Блин, это ж DBF! Тогда ты прав. Я все в мозгах SQL держу. Сори.

Johnmen (2002-04-26 11:23:00) [10]
>Kouzmine © (26.04.02 11:04)
Что есть "текущий порядок" ?

Kouzmine (2002-04-26 11:18:00) [11]
Ребята. Все это фигня. Справки для одного человека двадцать бухгалтеров делать не будут по простой причине, что эти справки выдаются по требованию. И только дебил будет просить их сделать у всех имеющихся бухгалтеров, тем более одновременно. А так пересчет идет не по всей базе, а подчиненных записях, только!!!!! одного человека.

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

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

Kouzmine (2002-04-26 11:07:00) [13]
А Х может быть что угодно. Это вообще не важно. Единственное, что для прядка надо сделать X.First;

Kouzmine (2002-04-26 11:04:00) [14]
Срать на порядок. Будет пересчитываться в текущем порядке.

Johnmen (2002-04-26 10:51:00) [15]
>Kouzmine © : Ты не совсем осознаешь, что может скрываться за Xв твоем примере, и того факта, что в его НД никак не учитывается порядок !

Lusha (2002-04-26 10:50:00) [16]
Просто при таком подходе можно обрабатывать запрос типа
select sum(field1) from table where id<:id_current. Получится намного быстрей и проще...
Быстро, просто, но неправильно. Второй пользователь тоже не дремлет... :)

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

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

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

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

Kouzmine (2002-04-26 10:40:00) [18]
Я так понял, что нарастающий итог нужен по каждому человеку в отдельно. Если это так, то имеется главная таблица и подчиненная. Тогда, на смену записи в главной, сделать так в подчиненной. (Дополнительное поле необходимо)
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. Работать должно почти мгновенно.

Lusha (2002-04-26 10:16:00) [19]
Для ежедневного получения справок по зарплате работников за несколько лет, вы что собираетесь каждый раз считать ее (зарплату)?
Не надо передергивать на счет ежедневного... :)

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

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

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

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

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »