Re: Convert CHAR to NUMERIC and vice versa
Posted in 1993
Topics: Stored Procedures & SPL, Error Codes & Troubleshooting, Connectivity: ESQL/C, 4GL & Embedded SQL, Jobs, Consulting & Announcements
In article <531@rhlab.UUCP> kuhn@rhlab.UUCP (mjk Michael Kuhn) writes: >In article <1993Mar9.042901.20762@informix.com>, aland@informix.com (Colonel Panic) writes: >> In article <18670@autodesk.COM> johnge@Autodesk.COM (John George) writes: >> >To convert a char to numberic: >> > >> > #### Add a Zero >> > LET numericvar = charvar + 0 >> >> You don't need to add a zero; just do LET numericvar = charvar >> >> >{IF IT'S NOT A VALID NUMBER; NUMERICVAR WILL = ZERO } >> >> No, if it's not a valid number, "status" will be nonzero, and the value of >> numericvar is undefined. >> >> >> -- >> Alan Denney aland@informix.com {pyramid|uunet}!infmx!aland >> > >Alan, > > According to information I was given by Tech Support (RE: Case #206687) > you cannot trap for conversion errors. > > In release 4.10 of 4gl the status variable is not set after a > string to numeric conversion error. In addition the "whenever error stop" > does not halt the program when this occurs. It generates error to > stdout and keeps on running. > > This DID work in release 4.00, because I had used it in a number > of places to detect bad data from barcodes and laboratory equipment. > > w integer, > ch char(3) > > let ch = "12A" > whenever error continue > let w = ch > if status <> 0 then > display "bad data" at 10, 1 > end if > whenever error stop > > THIS DOES NOT WORK IN 4.1 > > I was told that this was not a bug and is intended to work this way. > >-- >Michael J. Kuhn Consultant phone:410-254-7060 >Email: rhlab!kuhn@uunet.uu.net or uunet!rhlab!kuhn > c/o Baltimore Rh Typing Laboratory, Inc. phone:410-225-9595 To get your desired results, either a) change "whenever error" to "whenever any error" or b) use the -anyerr option when compiling. The reason for this change is to "unbreak" pre-4.0 applications which assume that only SQL statements set the status variable. The 4.0 feature that makes status a frontend/backend concept caused two kinds of problems: o incompatible behavior for programs which delayed status checking by one or more statements following an SQL statement, and o unwanted codesize increase for the new frontend statement status manipulation. Therefore 4.1 was modified to allow either behavior, selectable either globally or on a per-statement basis. Martin Herbach Informix