Hi, John!
Thanks for the questions.
It sounds like you're storing weights as both pounds (Wt) and grams (Weightg).
Actually, the query is returning [Wt] from a stored value *IF* it exists.
This value might be in g, lb., or some other UOM therefore, a conversion is
necessary to get it to lb.
Sometimes there won't be a value for [Wt] therefore the user must enter a
weight value in g in the [Weightg] field. The reason for g is that it's the
more typical/accurate UOM for packaging weights which this entire ordeal
involves. Once this weight is entered in g it needs to be converted to lb.
which is the preferred unit when reporting weights to customers or into
systems.
Hence:
PTPKWtlb: IIf([Wt] Is Not Null,[Wt]*[lbConvFactor],IIf([Weightg] Is Not
Null,[Weightg]*0.002204622622))
That could be a pretty severe structural problem - it allows for the
possibility that you might have 2.0 in Wt and 350 in Weightg!
Yes. This is a bit of a pain. I've tried to add a query to my datasheet
subform so that if a [Wt] exists then it will appear in a textbox which I
could then use in event procedures to eliminate that possibility.
Unfortunately, I haven't figured out how to do this yet as my first attempt
resulted in making the subform un-updatable. Not to worry too much as I'm
currently the only user of this function.
One of them has
to be wrong. What's the value of lbConvFactor? Is it variable from record to
record, and if so why doesn't it play a role in the Weightg calculation?
The value of lbConvFactor comes from tblUOMWeightMass in which are stored
UOM values (i.e., "g", "lb.", "oz.", etc.) and fields that hold conversion
factors to convert them to other UOM's.
And what result do you want if both Wt and Weightg are NULL? Your second IIF
has only two arguments, not three!
That *should* never happen.
