Re: Checking datatype of CHAR variable in 4GL

We did up an error routine once which was invoked on the whenever clause. It captured everything there was to get from the SQLCA record, whatever it could interpret from that data (error message, table, column, etc) and then went out and checked the executable in question - doing a 'what' which told us what version of everything was built into the executable - popped all of this into a nice error message and mailed it to $ADMIN. Not that hard to do up - the only issue is changing your 'whenever' clause in each module and adding an 'ident' variable to store the RCS header info. But then I have a little utility... cheers j. David Williams <djw@smooth1.demon.co.uk> on 02/15/98 06:09:53 PM Please respond to David Williams <djw@smooth1.demon.co.uk> To: informix-list@iiug.org cc: (bcc: Jack Parker/Boston50/Epsilon) Subject: Re: Checking datatype of CHAR variable in 4GL In article <6c6v2u$134$1@news.xmission.com>, Marco Greco <marcog@linux.ctonline.it> writes > >That's exactly what I meant, Alan. Form errors (i.e. conversion errors, for >instance) are logged in the error log even after a WHENEVER ANY ERROR CONTINUE, >which obviously isn't the correct way of handling errors. > >To make it more clear, this is the contents of my error log after running the >following useless program (4gl/c 4.16UC2 x SCO 3.2.5.0) > >main > define a smallint > > whenever any error continue > call startlog("error.log") > let a="a" >end main > >Date: 02/15/1998 Time: 14:56:48 >FORMS statement error number -1213. >Character to numeric conversion error > Don't you just hate the fact that there is no program info, no module info and no line number info in that error message. On on of our customer sites were are seeing ten's of these messages per day. But we have over 250 programs in our product!!! How can we hope to trace these problems when users don't even log them? Or course eventally we'll end up with crap data in the database and no idea where it came from...even a debugging enviroment variable to cause a core dunp would be better than nothing... >Ciao, >Marco >__________________________________________________________________________ _____ >Marco Greco, Catania, Italy marcog@linux.ctonline.it >rem radioterapia +39 95 447828 fax 446558 > >Informix faq http://www.iiug.org/techinfo/faq/informix.htm >4glworks http://www.ctonline.it/~marcog >Informix on Linux http://www.ctonline.it/~marcog/ifmxlinux.htm > >Alan Denney wrote: >> >> In article <6c1tbj$2h5$1@news.xmission.com>, >> Marco Greco <marcog@linux.ctonline.it> wrote: >> >Nice try Jack. >> >That's what I've been doing for a long time, until I discovered that, >starting >> >from 4gl 4.13, non fatal errors where added to the error log all the same :-( >> >> Um, that's what the log is there for. >> >> The point is: the program flow itself is unaffected. >> >> If the log contents matter that much to you, you can stop and start >> error logging when you change WHENEVER from STOP to CONTINUE and vice-versa. >> >> -- >> Alan Denney yosemite_at_netcom.com >> >> "I do not like this word 'bomb'. It is not a bomb. It is a device which >> is exploding." >> -- Jacques Le Blanc, French ambassador to New Zealand, referring to the >> nuclear 'devices' France is testing in the South Pacific -- David Williams Maintainer of the Informix FAQ Primary site (Beta Version) http://www.smooth1.demon.co.uk Official site http://www.iiug.org/techinfo/faq/faq_top.html I see you standin', Standin' on your own, It's such a lonely place for you, For you to be If you need a shoulder, Or if you need a friend, I'll be here standing, Until the bitter end... So don't chastise me Or think I, I mean you harm... All I ever wanted Was for you To know that I care