Just like real database columns, calculations may be placed as fields on forms, used in data labels, and requested programmatically.
A simple calculation subtotal on a database table order_details which yields a Number value; the unit price, multiplied by the quantity, with a discount applied.
This function is executed for the scope of an individual record. Notice that the record's other data providers, unitprice and quantity are immediately available.
This calculation could now be placed on a form or used in a method, just like any other real database column. The next code example shows another calculation, this time declared for the orders table, which uses the previous calculation to determine the total amount for the entire order.
Calculations may be optionally stored back to a real database column. This is called a Stored Calculation, and is achieved by creating a calculation which is the same name and data type as a real column. When the calculation is referenced, it will be executed and its result will be stored back in the database column.
Bear in mind that a stored calculation is not guaranteed to be recently calculated when used in a find, a sort definition, or as the right-hand key in a relation, because its value is computed in memory and the database value only represents the most recent execution of the calculation.
Calculation As a Record-Level Variable
In general, a calculation is a ready-only data provider, its value being generated each time it is read. However, in one exception a calculation may be used to cache data for a record, thus becoming a read/write in-memory data provider. This is done by creating a calculation which has no return statement. Such a calculation will be treated a little differently. It can actually store a value in memory for an individual record.
Example In this example, a record-level variable is created by defining an empty calculation.
Next a method illustrates how the calculation may be used to store, in memory, information about the record.