At 04:51 AM 14/06/2003 +0000, you wrote:

>which could be the best practice...
>
>lets take this table for example ...
>
>table 1 has the following column, id, description, qty, price.
>
>I want to put a calculated field for table 1 which is the subtotal
>field.
>
>option 1. in they T_query1.sql I will put select *, "qty"*"price"
>as "subtotal" from "table 1"

This is OK.

>option 2. in they T_query1.calculated fields properties will I
>declare the "subtotal" field.

This is OK too. It is more work for the client than is option 1, but it
saves the need to go back to the server to refresh it.

>option 3. Iam not so sure if this is possible, under the column
>attributes I will add a new field "subtotal" then check the computed
>check box.

No. The column attributes apply to columns that the dataset already "knows
about" - either as described by the server during the Prepare, or as
defined to the dataset as a calculated field.

>What is the use of the computed attributes under the column
>attributes besides from when we are using it for setting up a
>TIB_lookupcombo

The COMPUTED attribute tells the dataset that the column is not a database
column, so that it will know not to try to update it.

>please explain the option you think is the best practice.

1 and 2 are both OK. For some requirements, you may prefer to use a
calculated field, where a user edit on a related column in the buffer will
affect the value of the calculated field. You can just call calculatefield
to update it in the UI, without having to requery the server.

If you can wait until the edited row is updated to the server and the
invalidated row is refreshed, then the computed output field is more efficient.

Helen