Failure of Select with data conversion error

[Deskin, Bob]

Unfortunately this can be argued either way.

One way to look at it is that if there is a data conversion error then the
test failed. If the test failed, then it's false and we continue based on
that condition.

Another way of looking at it is that if there is a data conversion error,
then the data going into the test is incorrect and we can't run the test.
Therefore we don't know if the test passed or failed and therefore whether
the condition is true or false. This is a very relational view of things.
It's the same as testing against a column that is NULL. The test is
undetermined because a NULL column doesn't exist.

By the way, it seems from the tests on DEFINEs that things are consistent.
With your second DEFINE example, the data conversion error causes neither
value to be set.

My recommnedation on this bug will be based on history. If PowerHouse has
always done things this way, then they should not change. There is too much
chance of impacting existing working reports.

Bob Deskin              
PowerHouse Web Product Manager and Senior Product Advisor
Application Development Tools, Cognos Inc.
bob.deskin@cognos.com (613) 738-1338 ext 4205 FAX: (613) 228-3149
3755 Riverside Drive P.O. Box 9707 Stn. T, Ottawa ON K1G 4K9 CANADA


> ----------
> From: 	Jeff Hoffman[SMTP:J.Hoffman@cchs.usyd.edu.au]
> Sent: 	August 12, 1999 4:59 PM
> To: 	powerh-l@lists.swau.edu
> Subject: 	Failure of Select with data conversion error
> 
> FYI
> 
> I am running PH710G1 (& 710E6) on OpenVMS v7.1 on an Alpha.
> 
> Just found out that a select will fail if there is a data conversion error
> during the if test. (QUIZ,QTP&QUICK) 
> 
> This has been reported to COGNOS Call No 974364 Bug No 270079, although
> reported as applying to Zdate it applies to any numeric field that
> generates a data conversion error.
> 
> Example:
> 
> File_1 contains 
> 
> key (char*1)    suspect_field (zoned*3)
>  1                   100
>  2                   200
>  3                   0x0
>  4                   010
>  5                   300
> 
> acc file_1
> sel if suspect_field <= 100 or &
>         key > "2"
> rep key suspect_field
> go
> 
>  key     suspect_field
>   1          100
>   4           10
>   5          300
> 
> Records selected: 3
> *W* ** Data conversion errors: 1
> 
> Note: The 3rd record did not get selected even though the value of key is
> >
> 2, due to the data conversion error on suspect_field during the if test.
> 
> If I alter the program slightly, by moving the data conversion error to a
> define:
> 
> acc file_1
> def sus_field = suspect_field
> sel if sus_field <= 100 or &
>         key > "2"
> rep key suspect_field sus_field
> go
> 
>  key     suspect_field      sus_field
>   1           100              100 
>   3          ####                0
>   4            10               10
>   5           300              300
> 
> Records selected: 4
> *W* ** Data conversion errors: 3
> 
> NOTE: The 3rd record is now reported, correctly?.
> 
> Note: 3 data conversion errors! when the define of sus_field is evaluated
> during the if test, again when it is evaluated for reporting and the 3rd
> when suspect_field is reported?
> 
> 
> Has anybody run across this problem?
> 
> I believe the if test on the select should NOT have failed in example 1.
> 
> Your comments please.
> 
> PS I have not tested the effects of the on 'define ... if' statements, I
> will test that later today.
> 
> 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+
> + Jeff Hoffman                         + e-mail:
> J.Hoffman@cchs.usyd.EDU.AU +
> + Director                             +
> +
> + WoniCon Pty Ltd                      +                           ,-_|\
> +
> + 21 Prices Circuit                    +  voice: +61 2 9542 1527  /     \
> +
> + Woronora    NSW     2141             +    fax: +61 2 9521 3979  \_,-._*
> +
> + AUSTRALIA                            +                               v
> +
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> +
> = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> =
> Subscribe: "subscribe powerh-l" in message body to
> majordomo@lists.swau.edu
> Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
> powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
> This list is closed, thus to post to the list, you must be a subscriber.
> 
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.