[Uniq!]

Задачка такая:
пользователь должен добавлять в таблицу элементы: по принципу
заполняется поле А
заполняется поле Б
автоподсчёт поле С = А*Б;

Здесь первый вопрос. Если полю С выдать AutoCalc, и в onFieldCalc обрабатывать его подсчёт, то почему-то это значение не сохраняется в Таблицу. Что я делаю не так?

Далее с каждым новым элементом общая сумма по колонке С должна отображаться на форме.

Вторая часть реализована следующим образом:

Код:

var
  TotalPrice: real;
begin
  with fMain.Items do
  begin
    Post;
    TotalPrice := 0;
    First;
    while not Eof do
    begin
      TotalPrice := TotalPrice + FieldByName('Price').AsFloat;
      Next;
    end;

    maxPrice.Text := FormatFloat('0.00', TotalPrice);
    maxLoan.Text := FormatFloat('0.00', TotalPrice * 0.76);
  end;

Получается, что каждый раз программа пересчитывает предыдущие элементы. А если их будет 100, и добавляться 101 ... а если 1000.

Была мысли уйти от ADOTable и воспользоваться ADOQuery и запросом (SUM), но как-то весь проект в таблицах.) Это скорее эстетика. Может стоит отказаться от таблиц?

[Mrak]

Конечно отказывайся, пока не стало еще хуже
Если таблицы есть и их много и не охота переделывать, то сделай симбиоз с квериками

Бд - доска, таблицы - топор, кверики - электролобзик))

[Freeman]

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

На самом деле задача подсчета итогов прямо в процессе ввода нетривиальна для DB-компонентов и является частным проявлением проблемы размазывания логики между клиентом и сервером. Подсчет суммы агрегатной функцией sum на сервере -- это одно, а подсчет и функцией на сервере, и еще какими-то костылями на клиенте во время ввода -- это другое. Без костылей, к сожалению, не получается, поскольку большинство DB-компонентов не умеют делать это штатно. ADO в их числе, но в других компонентах я что-то тоже такого не припомню.

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

[Страдалецъ]

Все несколько не так.
Если вы хотите только видеть результаты в таблице то вам нужно использовать calcfield. Но! Имейте ввиду что это по сути виртуальное поле и живет оно только на экране. Обратится извне к нему не выйдет ибо его в таблице физически не существует. Более приятный и удобный способ - это сделать запрос с вычислением. Вот тогда уже можно к такому полю обратится извне. Но и тут без подводных камней не обойдется если вам нужен подсчет при вводе.

[Uniq!]

Ребят, вот wiki:fkInternalCalc.
Я так понимаю, это мой ключ от замка к первой части задачи.

Только вот справиться с ним не могу.
1) Двойной клик на "открытом" TADOTable (т.е. DataSet заполнен)
2) Добавляю все колонки
3) Выставляю нужным колонкам в свойствах fkInternalCalc
4) Обрабатываю в OnCalcFields подсчёт этой колонки:

Код:

procedure TfMain.ItemsCalcFields(DataSet: TDataSet);
begin
  DataSet.FieldByName('MetallWeight').AsFloat := DataSet.FieldByName('Weight')
    .AsFloat - DataSet.FieldByName('InsertWeight').AsFloat;
  DataSet.FieldByName('Price').AsFloat := DataSet.FieldByName('MetallWeight')
    .AsFloat * DataSet.FieldByName('Pricep1g').AsFloat;
end;

Обычно, при вводе в связанные с DataSet'ом TDBEdit'ы, изменения сразу отображаются в DBGrid. А вот с fkInternalCalc ничего не происходит.

С TADOQuery не работал. Пока попробую вникнуть.

[Freeman]

Сообщение от Uniq!

А вот с fkInternalCalc ничего не происходит.

Во, век живи, век учись. Раньше думал, что fkInternalCalc -- для совместимости с древними версиями VCL, гвоздями прибитыми к BDE. Ан нет.

Как понимаю, этот вид поля предназначен для вычисляемых полей с кэшируемыми значениями, которые и хранятся в наборе данных. Не поленился и посмотрел в исходниках, как это реализовано. Похоже, что это базовая функциональность, реализованная в модуле DB и унаследованная всеми наследниками TDataSet. Стало быть, и в ADO должно быть.

Как можно догадаться, я сам fkInternalCalc ни разу не пользовал... Могу предположить, что значения этих полей нужно изменять вместе с изменением основных полей, раз они физически хранятся в наборе данных. Если сработает, мне придется посыпать голову пеплом взять назад свои слова об отсутствии в DB-компонентах возможности подсчета на лету.