See comments in-line.
-Tom.

They do work, but they are not appropriate since calculated values
don't belong in tables (barring sensible exceptions). Say that you did
include Volume. Then someone comes in and updates the Length field.
Will you remember to recalculate Volume? Under all circumstances,
perhaps outside of your app?
Rather you calculate Volume when you Select from your table.

Granted, but even Nasa engineers can't always get it right.
http://www.cnn.com/TECH/space/9909/30/mars.metric/. One suggestion
would be to include the Unit of Measure in the field name: Length_cm.

Assuming those fields exist, the formula is correct. The outermost
parentheses are not needed. If you temporarily switch it to a Select
query, you can see for yourself.
You don't have Null values, right? All calculations with Null result
in Null.

I don't know if you're trying to create a table in Access or in
AS/400. Assuming the former, one suggestion is that you cast the
result to a Double, which I hope would be enough of a hint to Access
(better: Jet) to create a Double field. Casting is done by wrapping
your expression with CDbl( ).  Another suggestion is that you create
the table first, and then fill it using an Append query.

Jet does not support the Standard SQL syntax:

CAST(<cast operand> AS <cast target>)

Instead, it uses the casting functions from the VBA expression
service, despite the fact they generally do not handle the NULL value;
there isn't a one-to-one mapping of Jet data type to VBA casting
function either. VBA does have a 'cast to DECIMAL' function which Jet
could in theory use but it is 'broken' when called via in Jet
(including ACE):

ACC2000: "Wrong Number of Arguments" Error When You Use CDec Function
in a Query
http://support.microsoft.com/kb/225931/en-us

This is often not a problem in practice because decimal values
(between certain limits) are considered natively as being of type
DECIMAL by Jet e.g.

SELECT TYPENAME(0.5);

returns 'Decimal'.

I think the problem you have is that, in Jet, division results in a
value of type FLOAT (a.k.a. Double) unless a value involved is already
of type DECIMAL e.g.

SELECT 4 / 2, TYPENAME (4 / 2);

returns 'Double', whereas

SELECT 4.4 / 2, TYPENAME(4.4 / 2);

returns 'Decimal'.

Further note that arithmetic involving a value of type DECIMAL coerces
the result to type DECIMAL e.g.

SELECT 4 + 0.2 - 0.2, TYPENAME(4 + 0.2 - 0.2);

So, something you could try is, instead of dividing by 1000000,
multiply by 0.000001 e.g.

SELECT 123456789 AS value_integer,
123456789 / 1000000 AS result_double_value,
TYPENAME(123456789 / 1000000) AS result_double_type,
123456789 * 0.000001 AS result_decimal_value,
TYPENAME(123456789 * 0.000001) AS result_decimal_type;

Jamie.

--