[AccessD] NZ for Null

AD,

Thanks.  I agree entirely.  I can't remember details, but in the past I 
have experienced unpredictable results with calculated fields in queries 
involving the use of Nz(), that was only resolved by converting the Nz() 
element separately.  So I have got into the habit of treating each 
element separately first.  But you are right, it is illogical, and 
probably over-reacting in the context of this example.

Regards
Steve


A.D.TEJPAL wrote:
> Steve,
> 
>     Don't you think data type enforcement function wrapped around overall  expression for the calculated field should suffice, instead of converting each element separately ?
> 
>     Example (RDate is date type field while RNum & SNum are number type fields):
>     (a) Date type output:
>         CDate(Nz([RDate],Date())+Nz([RNum],0))
>     (b) Number type output:
>         Val(Nz([RNum],0)+Nz([SNum],0))
> 
>     Note - It is also observed that the output of a calculated field in a query is a string only when it is a single element Nz() expression like 
> Nz([RDate],Date()) or Nz([RNum],0). If there is interaction involving mathematical operators, the output is seen to be a number even without application of a data type conversion function. However, for date type, use of CDate() becomes necessary so as to display dates rather than equivalent date serials. All in all, it would be a safe practice to apply the conversion as per (a) & (b) above universally when using Nz() function. Similar precaution becomes necessary in case of domain aggregate functions.
>