Re: INPUT ARRAY delete

Path: emory!europa.asd.contel.com!uunet!ispd-newsserver!kodak!static!amiano From: amiano@static.Kodak.Com (Mitch Amiano) Newsgroups: comp.databases.informix Keywords: INPUT ARRAY, delete Message-ID: <1991Oct15.125915.8237@kodak.kodak.com> Date: 15 Oct 91 12:59:15 GMT References: <1991Oct15.063248.27613@qualcomm.com> Sender: amiano@static (Mitch Amiano) Organization: Eastman Kodak Co., Rochester, NY In article <1991Oct15.063248.27613@qualcomm.com>, g_arne@bigbird.qualcomm.com (Arne Mortensen...guest) writes: |> I often use INPUT ARRAY WITHOUT DEFAULTS and I typically end up doing |> some kludgy thing to allow the user to bail out of a DELETE. For |> example, if the user pressed DELETE on a row, I ask the user to confirm |> the action and if the action is not confirmed, I EXIT INPUT and re-issue |> the INPUT ARRAY (now updated up to the last user action). It would seem |> that Informix should have the capability to allow the program to abort |> the DELETE without forcing an abortion of the entire INPUT ARRAY. |> Similarly, there are times that I want to restrict the user from performing |> an INSERT. |> |> I would appreciate any comments or suggestions. Suggestions: 1. Try using the BEFORE INSERT, BEFORE DELETE clauses, etc., to terminate the action before it gets a chance to happen. Has anyone tried this, does it work, not work ? 2. If that doesn't work, a kludgier (?) thing to try is keeping a second program array, identical to the one being INPUT; use the same BEFORE INSERT, BEFORE DELETE clauses, but try using the I4GL library functions to reset the scr_count() value, and the second program array to restore the 'lost' row. I have NOT tried this, but it may be possible. Or not. Again, has anyone tried something to this effect ? Comments: 1. Yup, sometimes it seems that Informix should have some capabilities it is currently lacking, especially when we hit the limitations head on. My own pet peeves with the language include the CONSTRUCT statement; its lack of ON KEY and AFTER/BEFORE clauses crimps its versatility. On the whole, I would rather they keep the product stable and less functional than unstable. ---------------------------------------------------------------------------------- Mitch C. Amiano, Software Contractor Rochester NY 716-226-2024 Disclaimer: My employer doesn't have an internet connection, wouldn't know what to do with one, and doesn't know I have one, so my opinions are my own.