Re: Fwd: Identifying numeric string in a 4gl program

It's a trade-off. You can leave the error_log set to a legitimate file, and let errorlog() file its complaints when it finds a non-numeric in a numeric field... Andrew Hamm wrote: > > Colin McGrath wrote in message <92026u$5g0$1@news.xmission.com>... > > > >To avoid writes to the error log file when the conversion of a string > >to a numeric fails, you have to pepper your code with a new startlog() > >call in those sections where you don't wish to see the error reported; > >the same sections you put your "whenever any error continue" statements. > > > Have you too found that this causes very noticable code slowdowns as the > error log file is closed, opened, closed, opened at each place in the code? > Especially in a tight loop of a data loading process for example. > Unfortunately, the sober need for error reporting on all the other lines of > code make me extremely reluctant to wrap the entire loop with a /dev/nul log > file. When I tried that trick it caused users to be very uncomfortable, and > had to abandon the approach. I'm surprised it's not "fixed" yet, for example > by silencing the errlog report when a suitable WHENEVER condition is > applied. Is it true? Nothing can silence the log except for pointing to a > nul log file? How sad is that? > -- Colin Any opinions I state are my own and not necessarily those of my employer

Colin McGrath wrote: > It's a trade-off. You can leave the error_log set to a legitimate file, > and let errorlog() file its complaints when it finds a non-numeric in a > numeric field... Switching log files would be slow. If you need the validation done more quickly, then the best thing is to use some C code to do the conversion for you. I've forgotten the original context, but I'd expect to write one or more functions that take a string and returned two values, one an error code or zero for OK, and the other the actual converted value. You could even decide just to return the error code and let I4GL (re)do the conversion if there wasn't an error detected by the validation code. Depending on whether you're after integers or decimals, I'd either use the C library strtol() or the ESQL/C deccvasc() functions, probably. I4GL will take care of most of the rest of the conversion issues. You might need to worry about accepting 1e33 into a DECIMAL(4,2) field; this would cause problems when the conversion code returned a big value into a decimal not sized to take it. If that's an issue, then you need to specify the scale and precision in the call for the decimal conversion routine -- a nuisance. There are a variety of ways it might be made easier, but they are all still a nuisance. > Andrew Hamm wrote: > > Colin McGrath wrote: > > >To avoid writes to the error log file when the conversion of a string > > >to a numeric fails, you have to pepper your code with a new startlog() > > >call in those sections where you don't wish to see the error reported; > > >the same sections you put your "whenever any error continue" statements. > > > > > Have you too found that this causes very noticable code slowdowns as the > > error log file is closed, opened, closed, opened at each place in the code? > > Especially in a tight loop of a data loading process for example. > > Unfortunately, the sober need for error reporting on all the other lines of > > code make me extremely reluctant to wrap the entire loop with a /dev/nul log > > file. When I tried that trick it caused users to be very uncomfortable, and > > had to abandon the approach. I'm surprised it's not "fixed" yet, for example > > by silencing the errlog report when a suitable WHENEVER condition is > > applied. Is it true? Nothing can silence the log except for pointing to a > > nul log file? How sad is that? -- Yours, Jonathan Leffler (Jonathan.Leffler@Informix.com) #include <disclaimer.h> Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN "I don't suffer from insanity; I enjoy every minute of it!"