Re: Strange behaviour of case

Michael Krzepkowski wrote: > Running on Suse 9.0, IDS 9.40, RDS 7.32UC1 > > The following code example always displays "other". > The value retrieved by select is '3' (one char) > > Works fine with 7.20UD7 on sco. > > database master_db > define g_one_char char(1) > MAIN > case lib() > when '1' > display 'one' > when '2' > display 'two' > when '3' > display 'three' > when '9' > display 'error' > otherwise > display 'other' > end case > END MAIN > FUNCTION lib() > define ret_val char(1) > select orders_by into ret_val > from global > return ret_val > END FUNCTION Do you know if there is a row in the 'global' table? Just one row? If not, don't bother to log a problem - you're playing with uninitialized variables (because the SELECT doesn't work properly). What logging mode is your master_db database? Different modes have different default behaviours on error - IIRC, it is stop on non-ANSI databases, and continue in MODE ANSI. Have you looked to see exactly what the 'other' value is? If it is null, that would be another indicator of problems with the SELECT. Is there any significance to the variable g_one_char? It seems irrelevant in this reproduction. > Is this a known bug? Should I log a call? The jury hasn't heard sufficient evidence; at best, it can do what Scottish juries can do - return a verdict of 'not proven'. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

Jonathan Leffler wrote: > Michael Krzepkowski wrote: > >> Running on Suse 9.0, IDS 9.40, RDS 7.32UC1 >> >> The following code example always displays "other". >> The value retrieved by select is '3' (one char) >> >> Works fine with 7.20UD7 on sco. >> >> database master_db >> define g_one_char char(1) >> MAIN >> case lib() >> when '1' >> display 'one' >> when '2' >> display 'two' >> when '3' >> display 'three' >> when '9' >> display 'error' >> otherwise >> display 'other' >> end case >> END MAIN >> FUNCTION lib() >> define ret_val char(1) >> select orders_by into ret_val >> from global >> return ret_val >> END FUNCTION > > > Do you know if there is a row in the 'global' table? Just one row? Yes there is only one row of data and the column value is '3' > If not, don't bother to log a problem - you're playing with > uninitialized variables (because the SELECT doesn't work properly). What > logging mode is your master_db database? Different modes have different > default behaviours on error - IIRC, it is stop on non-ANSI databases, > and continue in MODE ANSI. Have you looked to see exactly what the > 'other' value is? If it is null, that would be another indicator of > problems with the SELECT. Non-ANSI database. REturn value is '3' (when displayed before return from function). > > Is there any significance to the variable g_one_char? It seems > irrelevant in this reproduction. > Just from my fooling around with the test program. Sorry. >> Is this a known bug? Should I log a call? > > > The jury hasn't heard sufficient evidence; at best, it can do what > Scottish juries can do - return a verdict of 'not proven'. > So, should we give it a fair trial and then hung it? Michael