home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / database / informix / 2378 < prev    next >
Encoding:
Internet Message Format  |  1992-11-10  |  2.7 KB
  1. Path: sparky!uunet!usc!sol.ctr.columbia.edu!emory!emory!not-for-mail
  2. From: johnl@obelix.informix.com (Jonathan Leffler)
  3. Newsgroups: comp.databases.informix
  4. Subject: Re: defer interrupt.
  5. Date: 11 Nov 1992 03:33:08 -0500
  6. Organization: Mailing List Gateway
  7. Lines: 46
  8. Sender: walt@mathcs.emory.edu
  9. Distribution: world
  10. Message-ID: <1dqgg4INNm65@emory.mathcs.emory.edu>
  11. Reply-To: johnl@obelix.informix.com (Jonathan Leffler)
  12. NNTP-Posting-Host: emory.mathcs.emory.edu
  13. X-Informix-List-ID: <list.1585>
  14.  
  15. >From: uunet!rhi.hi.is!gaukur (Kristjan Gaukur Kristjansson)
  16. >Subject: Re: defer interrupt.
  17. >Date: 9 Nov 92 13:22:18 GMT
  18. >X-Informix-List-Id: <news.2090>
  19.  
  20. >>Did you read pages S-29 - S-32 (in the English version, anyway) of the
  21. >>4GL 4.1 Supplement document? If so, what was unclear?
  22.  
  23. >Yes I've read them, but maybe theres something wrong with my configuration.
  24. >In my test exemplar I'm interrupting a foreach loop thats fetching rows
  25. >and getting some of them into a report.
  26.  
  27. All is revealed...  The problem is that reports are pigs to break into, not
  28. that the defer interrupt stuff doesn't work particularly.  Reports always have
  29. been neear enough impossible to interrupt, and they haven't changed recently.
  30. If you subject the program to blizzard of interrupts, then eventually, you
  31. usually manage to get a report to acknowledge that an interrupt has occurred.
  32.  
  33. I haven't done exhaustive checking of SQL INTERRUPT ON but I think you
  34. will find it will work, except when there is a report in use.
  35.  
  36. One day when I get some time, I'll try an track down what it is about reports
  37. that makes them immune from interrupt, but they always have been like that.
  38.  
  39. >So is it maybe something wrong with my termcap?
  40.  
  41. No, but an interrupt at an inconvenient moment may throw the key handling
  42. code out of kilter.  That is the problem with interrupts...  They're never
  43. expected.
  44.  
  45. >Also one comment on the int_flag testing; if youre interrupting open, fetch,
  46. >close statements (with something in between) do you have to test the int_flag
  47. >after every statement (because you never know in loops where the ctrl-c will
  48. >hit)?  
  49.  
  50. You should check after the open (because if the staetment was interrupted,
  51. you don't have a properly open cursor with which to fetch data), after each
  52. fetch (because if the row wasn't fetched, you don't have any new data in your
  53. variables), and probably after the close (simply because you're about to go
  54. and do something with the fetched data, and ought to check that all was OK).
  55. You don't really need to check after each intermediate calculation; once per
  56. fetch loop is enough, nomally. (That assumes no nested SQL statements -- you
  57. should check after each database operation -- hence after open, fetch, close).
  58.  
  59. Yours,
  60. Jonathan Leffler (johnl@obelix.informix.com) #include <disclaimer.h>
  61.