Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!uunet!zephyr.ens.tek.com!tektronix!sequent!lugnut From: lugnut@sequent.UUCP (Don Bolton) Newsgroups: comp.databases Subject: Re: Informix RDS questions Message-ID: <52250@sequent.UUCP> Date: 4 Feb 91 18:34:49 GMT References: <52042@sequent.UUCP> Reply-To: lugnut@sequent.UUCP (Don Bolton) Distribution: comp Organization: Sequent Computer Systems, Inc Lines: 97 In article ahl@technix.oz.au (Tony Landells) writes: >In article <52042@sequent.UUCP> lugnut@sequent.UUCP (Don Bolton) writes: > In article ahl@technix.oz.au (Tony Landells) writes: > >I'm doing some development with Informix RDS and there are a couple of > >things I'd like to do but can't work out how... > > > >1. Avoid the ERROR statement scribbling over my windows in its > > unfriendly manner. If I could replace the current error > > printing routine, that would be good enough, and seems to > > be the only way to get it to be sociable... > > > DISPLAY "Error message text" AT 23,1 > >This isn't what I want...I actually have my own functions that display >errors nicely. The thing that really annoys me are the messages that >come from Informix itself that appear to be output as ERROR statements >(such as not inputting a required field, wandering off the end of the >program array with the arrow keys, etc.). Thus, I am hoping that if I >find a way to avoid the ERROR statements amusements, I will get rid of >these things over which I apparently have no comtrol. > > Or do you mean them "fatal errors" when the status returns "bad news" :-) > THose too can be rescripted to display your own messaging or call for > own functions whatever. Up to the developers imagination (and tenacity) > >No, those you can actually do something about with the WHENEVER >statement. > > WHY? does your program attemt to insert the null lines? Thats real easy > to test for and omit them when you're doing the actual insert. > > FOR counter = 1 TO arr_count() > IF p_varfile[counter].key_val IS NOT NULL THEN > INSERT INTO tablename (col, list) > VALUES (blah, blah) > ELSE > MESSAGE "" > END IF > END FOR > >This seems a bit sad, as the warning and the erroneous action are only >loosely associated. > Part of my correspondance course RDBMS training no doubt :-) > BEFORE ROW, AFTER ROW, BEFORE FIELD, AFTER FIELD > all of those allow you some leeway to handle input controll. > >This finished up being the only thing that appeared to work properly, >albeit with some sad repetition... > > OR Put a WHEN INFIELD on your first array field that won't let them > leave it blank > >I suspect this must be a 4.0 feature, and I forgot to mention that >this is for .03... The WHEN INFIELD seems totally unfamiliar to me. > No this has been around, an application I have that was written in 2.0 uses this, its part of CASE actually. Its isn't well doccumented though. I use it to force a user to remain in a manditory field until a value is input, rather than wait for the Informix built-ins to work. AFTER FIELD field list (of all possibly enterable fields in the array if you wish to create a case for each) CASE WHEN INFIELD(field_name) IF prog_file.col_name IS NULL THEN ERROR "Field cannot be left blank" NEXT FIELD field_name END IF WHEN INFIELD(X) IF etc END IF END CASE > Lotta options, Pain inna-rear when you are first trying the things out > though. Come to loathe the term SYNTAX ERROR have you? :-) > >No, but I thought that AFTER INSERT would be really whizzy, but it >doesn't appear to do anything terribly useful... If anyone thinks >this is being particularly unkind to INformix, then I will post an >extremely long explanation of what I was trying to do and what I >tried, and why it was unsatisfactory, ... I suspect the AFTER INSERT would be usefull for inserting dependant rows into child table IF a successful insert was done in the parent table. It would seem to be the only way to ensure some form of integrity in some cases, especially if part of the child rows id was part of a foreign key (aka serial) from the parent table. >Thanks for the input, >Tony.