Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!agate!shelby!unix!Teknowledge.COM!uw-beaver!zephyr.ens.tek.com!tektronix!sequent!lugnut
From: lugnut@sequent.UUCP (Don Bolton)
Newsgroups: comp.databases
Subject: Re: informix input array
Message-ID: <52969@sequent.UUCP>
Date: 12 Feb 91 22:47:38 GMT
References: <AHL.91Feb12191828@saussure.technix.oz.au>
Reply-To: lugnut@sequent.UUCP (Don Bolton)
Distribution: comp
Organization: Sequent Computer Systems, Inc
Lines: 67

In article <AHL.91Feb12191828@saussure.technix.oz.au> ahl@technix.oz.au (Tony Landells) writes:
>Well, I still seem to be fighting things, which suggests to me that
>I'm doing something wrong, so I thought I'd ask for help again.
>
>My problem is that I have a number of tables that only really contain
>a short code (for data entry) and a longer description (for reports,
>queries, etc.).  Given that each record EASILY fits on one line of the
>screen, I've been trying to use an INPUT ARRAY statement to manage the
>data.  The other important thing about these tables is that a lot of
>other tables will be dependant on them.
>
>Now, I think I've got around the problem of people hitting the insert
>key, moving away, then coming back and entering data "unnoticed" by
>specifying in the form file that the fields are REQUIRED.  However,
>how do other people handle the following:
>
>	user hits delete key, but the code is in use and therefore the
>	record cannot be deleted--can you catch this in a BEFORE
>	DELETE clause and force informix to STOP the deletion
>	operation?
>
Yep, call a function, tie it to BEFORE DELETE or on key DELETE
test away and script according to taste :-)

>	user types over some information, changing it--if the old code
>	isn't in use, no problem (just like a delete followed by an
>	insert), but if the old code is in use, you need to propogate
>	the change...  Do people just take copies of the data in a
>	BEFORE ROW (or FIELD) and then compare the values afterwards
>	to determine if it's been changed?
>
You can make in effect a POST CHANGE mechanisim doing just as you suggest

>Am I barking up the wrong tree?  Should I force the users back to a
>"one record per screen" approach with add/change/delete menu options?
>This would seem like a BIG waste of screen space, as well as making
>the process a lot slower for the user...
>
I get the vague impression that you are attempting to UPDATE table rows
from an input array. BAD IDEA, also VERY BAD IDEA to allow the user to
change the primary key value in the input array. BEFORE FIELD "P_key"
if p_file.P_key IS NULL THEN NEXT FIELD P_key ELSE NEXT FIELD "next field"
a quick (while I'm devouring lunch) memory flash. Informix reccomends a
"delete and re-insert" method of update in an input array. While not my
ideal choice, it does solve issues of switching between insert and update.

>Also, in the stores example code, they use the function fgl_drawbox()
>(or something like that, anyway).  I note that this is in one of the
>libraries, but not documented anywhere.  Am I missing some
>documentation, or are they using unsupported calls?
>
UNDOCCUMENTED UNDOCCUMENTED UNDOCCUMENTED UNDOCCUMENTED 

When I was at the official 4gl class, the instructor clued us in
on this. Funny you should spot it (was just about to play with it
in my project tracking application).

useage

fgl_drawbox(1,2,3,4)      the numbers mark the posistions you wish
			  for the box boundraies. Youll need to
			  experiment as to whether "2" is horizontal
			  or vertical. (not a real good note taker)
O>Thanks in advance,
>Tony.

Hope it helps