What Do ???????????????

What do, Disney Land, Disney World, and INPUT ARRAY have in common??? They are ALL MICKEY MOUSE OPERATIONS :-) Hello fellow masochists. I've been working with 4.1xxx here attempting to perform a common request allowing for conditional INSERTS/DELETES within an INPUT ARRAY, 4.1 has this little new command CONTINUE INPUT which DOES leave one on the current row in the array. Of course its "up to the developer to control display, tides, phases of the moon etc". By using a backup array and a working array I'm able to conditionaly restore, resequence etc the data on the screen as well as in the database, in fact this doesn't work bad at all EXCEPT..... Remember where in all their manuals they state one must do a SET_COUNT(arrsize) prior to using ANY BUILTIN that uses the keyword ARRAY. Well guess what, that value remains constant througout that iteration of the brain-dead builtin. Sorry Informix corporate folk but these tools SSSUUUUUUUUUUUUUCCCCCCCCCCCKKKKKKKKKKKKK. Ie: INSERT/DELETE (which you cannot stop from really occuring on a condit- ional basis) adds/subtracts from the initial value used in the INPUT ARRAY, subsequent calls to SET_COUNT(realsize) are HOPELESS as they have NO effect on the value in use by the current iteration of INPUT ARRAY. ABORTING an add stretches the array by one as the function really does add a row. Its behavior affects the automatic "toggle" of any BEFORE INSERT logic when subsequently encountering a "virgin" row at the "end" of the array, this means BEFORE INSERT logic also needs to be duplicated BEFORE ROW to catch those "fakes" at the end. I tried a number of BEFORE/AFTER scenarios to red- uce the logic to mere "macaroni", but atsa spicy meataball there :-( Fortunately using the INSERT KEY fires AFTER ROW and BEFORE INSERT and NOT BEFORE ROW (since you are already there I guess). So an inordinate ammount of flag passing isn't needed. DELETING is the bitch kitty though, in decrementing the counter EVEN though the original data values are restored and redisplayed, the section thats now "out of bounds" becomes "phantoms" and out of control. So far the most reliable solution I've encountered is a SET_COUNT(realsize + 20) where I force an overly large initial count. and since my select retrieves only > count(*) - 10, its beyond a reasonable expectation they'll ever hit the phantom zone. Anyway I'm having some user-types bang at it for awhile and see how it fares BUT... DOES ANNYONE out there know WHAT variable INFORMIX is reading/incrementing/ decrementing in INPUT ARRAY? Can it be addressed as to affect the value WITHIN THE CURRENT ITERATION?? CAN the KEYs be trapped and "nulled"? Ie: if before delete logic sez no, then DON"T LET THE DELETE KEY PASS GAS? I know this stuff exists somewhere it HAS to. the software has to see it to operate. And yes I took a stab at the WINTER 90 WHILE TRUE/EXIT/SCROLL tech note, its a good thing I didn't step in it. :-) Don "come on Informix we need real world functionality" Bolton