Re: Quitting an SQL query in 4GL
Posted in 1992
In article <1638@das13.snide.com>, dave@das13.snide.com (Dave Snyder) writes: |> In article <203903@unix.cis.pitt.edu>, smfst2@unix.cis.pitt.edu (Seth M |> Fuller) writes: |> > Doe anybody know how to abort an SQL query that is in progress in |> > a 4GL program when defer interrupt is on? |> Check out the example in Tech Notes "Spring 1989". The code is a little |> buggy though. Be aware that this method is obsolescent! A quote from the version 4.1 release notes: SQL statements can now be interrupted within a 4GL program. This feature is implemented as an extension to the OPTIONS section, used in conjunction with the DEFER INTERRUPT OR DEFER QUIT statement: OPTIONS SQL INTERRUPT { ON | OFF } This feature is fully documented in the INFORMIX-4GL Version 4.1 Supplement. The previously recommended method for interrupting SQL statements no longer works (Tech Notes, Spring 1989, "How to Interrupt An SQL Statement from INFORMIX-4GL and INFORMIX-ESQL"). All instances of this method can easily be replaced by using the new functionality. I haven't tried this yet, myself ... |> Is this something that really isn't needed in |> a 4GL program? Oh, my users would really like it. But from my point of view there's a problem with both the old method, and the new functionality of 4.1. What I would like is to defer interrupts (and set SQL INTERRUPT ON) for just short sections of code, in particular while doing the first fetch from a cursor. In the rest of the code I'd rather have interrupt kill the program, as usual. But once you "defer interrupt", you can't turn it back on, as least as far as I'm aware. So as I understand it, in order to allow my users to interrupt queries that are taking much longer than they expected, I would have to defer interrupts for the entire program, carefully checking at every appropriate point if an interrupt has come in. I'm reluctant to go through 20,000 lines of code making this change :-( If any one knows of a good way around this, I'd like to hear about it! -- Harry Bochner bochner@das.harvard.edu