Вычисляемое поле

← →
Fynjy1984 © (2006-02-06 10:45) [0]

Есть вычисляемое поле, которое вычисляется по формуле: если
запись первая А=0, иначе А=B+C (для простоты) , где C тоже вычисляемое поле (но из предыдущей записи), где в вычислениях используется A. Т. е первая запись получается нормальной: A=0, C=f(A=0)=x1, а во 2-й записи должно быть A=B+x1.

Я получал С из другого набора, когда поле не было вычисляемым, т.е. переходил на предыдущую запись в другом DataSet, а теперь походу влип.

← →
Sergey13 © (2006-02-06 10:51) [1]

Что-то сильно много понакручено, ИМХО.
Может стОит завести отдельный Датасет типа CDS и один раз заполнить его ручками в цикле.

← →
msguns © (2006-02-06 10:54) [2]

Если алгоритм вычислений построен на порядке следования записей в таблице (не НД !), то в такую таблицу надо добавить поле, задающее явно порядковый номер записи в таблице. Алгоритм же должен "плясать" от значения этого поля. При этом записи должны следовать строго в порядке возрастания. Правда непонятно, причем здесь "другой набор" ?

Хотя все это довольно странно. Подобный алгоритм расчета, ИМХО, явно порочен, т.к. совершенно непонятно, ЧТО делать при добавлениях или удалениях записей (пересчитывать калк-поля ?).

В-общем, без внятного описания задачи невозможно посоветовать что-либо вразумительное

← →
Виталий Панасенко (2006-02-06 10:57) [3]

Только интересно, что делать после вставки/упорядочивания ?

unit Unit1;

interface

uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
Db, Grids, DBGrids, DBTables, StdCtrls;

type
TForm1 = class(TForm)
DataSource1: TDataSource;
Table1: TTable;
DBGrid1: TDBGrid;
Table1NAME: TStringField;
Table1SIZE: TSmallintField;
Table1WEIGHT: TSmallintField;
Table1AREA: TStringField;
Table1BMP: TBlobField;
Table1F: TFloatField;
Button1: TButton;
procedure Table1BeforeOpen(DataSet: TDataSet);
procedure Table1CalcFields(DataSet: TDataSet);
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
A : Variant;
public
{ Public declarations }
end;

var
Form1: TForm1;

implementation

{$R *.DFM}

procedure TForm1.Table1BeforeOpen(DataSet: TDataSet);
begin
A := null;
end;

procedure TForm1.Table1CalcFields(DataSet: TDataSet);
begin
if A=null then
A := 0
else
A := A + 1;
DataSet.FieldByName("F").AsFloat := A;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
Table1.Open;
end;

end.

← →
msguns © (2006-02-06 11:06) [4]

>Виталий Панасенко (06.02.06 10:57) [3]

1. Для определения порядкового номера записи в отображаемом НД, можно вполне обойтись без этих изгаляций, "положившись" на RecNo.
2. Ты уверен, что ему нужен № порядковый ?

← →
Виталий Панасенко (2006-02-06 11:22) [5]

> msguns © (06.02.06 11:06) [4]
> >Виталий Панасенко (06.02.06 10:57) [3]
>
> 1. Для определения порядкового номера записи в отображаемом
> НД, можно вполне обойтись без этих изгаляций, "положившись"
> на RecNo.
> 2. Ты уверен, что ему нужен № порядковый ?

Не уверен, но
> Fynjy1984 © (06.02.06 10:45)
> Есть вычисляемое поле, которое вычисляется по формуле: если
> запись первая А=0, иначе А=B+C (для простоты) , где C тоже
> вычисляемое поле (но из предыдущей записи), где в вычислениях
> используется A. Т. е первая запись получается нормальной:
> A=0, C=f(A=0)=x1, а во 2-й записи должно быть A=B+x1.

Просто я такую функуцию реализовал.
Это м.б. и A := Sin(A) и тд.Суть(я так понял) сводится к тому, что данные для расчета бертся из предыдуще итерации. Хотя, может ты и прав и человек так себе нумерует записи. Кто его знает ?

← →
msguns © (2006-02-06 11:31) [6]

>Виталий Панасенко (06.02.06 11:22) [5]

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

← →
Sergey13 © (2006-02-06 11:40) [7]

2[6] msguns © (06.02.06 11:31)
>порочность самого подхода
А как подсчитать, например, итог по нарастающей? Подход нормальный, ИМХО. Просто пользоваться им надо осторожно и к месту.

>Sergey13 © (06.02.06 11:40) [7]
>А как подсчитать, например, итог по нарастающей? Подход нормальный, ИМХО. Просто пользоваться им надо осторожно и к месту.

Вот никогда не понимал и не понимаю, зачем в динамически меняющихся данных при отображении надо обязательно в каждой записи показывать сумму (например) этой записи (или какого-то ее поля) с другими.
Итог - это ясно. А зачем нарастающий ? Ну, иногда бывает, согласен (например, при анализе динамики продаж внутри групп товаров или торговых точек), но это нужно делать в отчете, но зачем В ГРИДЕ ?

2[8] msguns © (06.02.06 11:50)
Я тоже не понимаю, зачем юзерам некоторые навороты. Самое печальное в этом, что деньги платят нам те самые юзера. 8-)

> Просто я такую функуцию реализовал.
> Это м.б. и A := Sin(A) и тд.Суть(я так понял) сводится к
> тому, что данные для расчета бертся из предыдуще итерации.
> Хотя, может ты и прав и человек так себе нумерует записи.
> Кто его знает ?

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

> Что-то сильно много понакручено, ИМХО.
> Может стОит завести отдельный Датасет типа CDS и один раз
> заполнить его ручками в цикле.

Согласен, наверное так и сделаю.

Вычисляемое поле Найти похожие ветки