Re: Checking datatype of CHAR variable in 4GL

Alan Denney wrote: > > In article <6ch9gn$p5q$1@news.xmission.com>, > Marco Greco <marcog@linux.ctonline.it> wrote: > ... > >- inconsistency with sql error trapping behaviour: a comparable example would be > > to prompt the user for a quick sql statement, and PREPARE it with WHENEVER > > ERROR CONTINUE in effect. in case of error, you are presented with a negative > > status & SQLCA.SQLCODE, and nothing in the error log. > > I'll agree that this should be programmer-selectable... but the behavior > is as documented under the startlog() function documentation. I have to agree with Marco here and I don't know why this should be programmer selectable. Consider the following: 1. With "whenever any error continue" the programmer has decided to trap error-codes himself. Conversion error-codes don't automatically crash the program and, reasonably, shouldn't automatically log to the error log. If the program is handling the error-code it can decide whether to log an error message. 2. The manuals effectively say that within a "whenever error continue" block, SQL error-codes aren't logged. While nothing is specifically said about the "whenever any error" statement, reason says it should be consistent with "whenever error". SQL error-codes are sometimes normal and so are conversion error-codes. 3. I can't imagine anyone being interested in a log file growing at a mad rate describing conversion error-codes that were handled by the program. To say that the error log isn't really an error log but a message log is kind of circumventing the issue. I do agree that the newer error handling methods in 4gl are an improvement. It would even be better with this seemingly minor adjustment of not logging errors that weren't errors. Best wishes, ---------------------------------------------------------------------- John H. Frantz Power-4gl: Extending Informix-4gl john@rl.is http://www.rl.is/~john/pow4gl.html