I am converting an app from BDE to DBISAM.
Just a quick question.
My old app used a fair amount of fields that were fkcalculated (SubTotals etc.).
Should I stick with these or use SQL to calculate the fields? Performance over
a wan is important.

David,

Do you mean executing SQL from inside OnCalcFields? If that is what you
mean, there is no general rule - it depends on the calculations you have
to do for each one of the calculated fields.
If the value can be calculated using only values from other fields in
the same record, then there is, in general, no gain in using SQL. On the
other hand, if you have to use values from other tables or from other
records in the same table, then SQL would be certainly better. Over slow
connections, the general idea is to minimize the amount of data you need
to retrieve for each record.

--
Fernando Dias
[Team Elevate]

Fernando Dias wrote:

David,

Do you mean executing SQL from inside OnCalcFields? If that is what you
mean, there is no general rule - it depends on the calculations you have
to do for each one of the calculated fields.
If the value can be calculated using only values from other fields in
the same record, then there is, in general, no gain in using SQL. On the
other hand, if you have to use values from other tables or from other
records in the same table, then SQL would be certainly better. Over slow
connections, the general idea is to minimize the amount of data you need
to retrieve for each record.

Thanks Fernando,
The values to be calculated in this case are:
A line item price item.ExtPrice(part.price * item.qty)
An order table total which is the sum
of all line items.

David


Something you don't indicate is f/s or c/s. Since you mention wan I'm assuming c/s

Roy Lambert

Roy Lambert wrote:


<<Something you don't indicate is f/s or c/s. Since you mention wan I'm assuming c/s>>

Yes, c/s

David,

> The values to be calculated in this case are:
> A line item price item.ExtPrice(part.price * item.qty)
> An order table total which is the sum
> of all line items.

For the order total you should use SQL.
For the other value I'm not sure I understand - do you mean item.price
is obtained calculating part.price * item.qty, where "part" and "item"
are tables ?

--
Fernando Dias
[Team Elevate]

Fernando Dias wrote:

>For the other value I'm not sure I understand - do you mean item.price
is obtained calculating part.price * item.qty, where "part" and "item"
are tables ?
Yes, exactly that.

--
Fernando Dias
[Team Elevate]

"David Darlison" <dave@ukweigh.net> wrote in message
news:E9A411C3-6E3E-403A-B56E-FF9B66187D1B@news.elevatesoft.com...
> Fernando Dias wrote:
>
>>For the other value I'm not sure I understand - do you mean item.price
> is obtained calculating part.price * item.qty, where "part" and "item"
> are tables ?
> Yes, exactly that.
>

If you need to hit other tables, definitely use SQL.

Robert

"Robert" wrote:

>If you need to hit other tables, definitely use SQL.
My problem with that is I am using cached updates so the item has to be posted
before any SQL calculations can be made.
eg
Post the item (save qty & price)
ApplyUpdate
Edit the item
Run SQL to calculate qty * price

or is there an easier way.

David

David,

> My problem with that is I am using cached updates so the item has to be posted
> before any SQL calculations can be made.

If the "Parts" table is small, you can also use a lookup field to get
parts.price, with "LookupCache" set to true.
Plese note that setting "LookupCache" to true is only an advantage if
there is a small number of records in the parts table.

--
Fernando Dias
[Team Elevate]