home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / database / ingres / 2377 < prev    next >
Encoding:
Text File  |  1993-01-28  |  2.5 KB  |  61 lines
  1. Newsgroups: comp.databases.ingres
  2. Path: sparky!uunet!tpghq!sfc
  3. From: sfc@tpghq.com (Steve Caswell)
  4. Subject: Re: Checking for SQL errors after commit
  5. Message-ID: <1993Jan28.142230.9603@tpghq.com>
  6. Organization: Palmer & Associates, Inc., Norcross, GA
  7. References: <26JAN199309454635@moose.cccs.umn.edu>
  8. Date: Thu, 28 Jan 1993 14:22:30 GMT
  9. Lines: 50
  10.  
  11. In article <26JAN199309454635@moose.cccs.umn.edu> mcj@moose.cccs.umn.edu writes:
  12. >
  13. >In our 4gl code we are currently suppressing ingres errors from database
  14. >selects / inserts / updates. We then check for the error in the subsequent
  15. >statement using inquire_ingres.
  16. >
  17. >i.e.    select a from tablex;
  18. >    inquire_ingres (error_no = errorno);
  19. >        if error_no !=0 then
  20. >        rollback;
  21. >        message 'Select error on tablex' with style = popup;
  22. >        rollback;
  23. >            return;
  24. >        endif; 
  25. >
  26. >Current coding does not check for an sql error after a commit statement.
  27. >I assume that an error can occur though during the commit and I am 
  28. >wondering how likely this occurrence is , or would any problem with the
  29. >transaction log file have manifested itself before the commit was actually
  30. >reached.
  31.  
  32. I have only seen commit fail once, and that was in a beta version of 6.4 when
  33. I was testing the set nologging feature.  If you want your code to be 100%,
  34. absolutely, positively bullet-proof, you should add an error check after the
  35. commit.  There is probably not much you can do to recover from the error, but
  36. you should at least tell the user (or a log file) that the commit failed and
  37. data may not have been stored.  A commit error could also possible cause an
  38. inconsistent database, depending on whether the error was in the log file.
  39. The only safe method of recovery is checkpoint/journal.  You can also mark
  40. your database as being consistent with the verifydb utility, using the 
  41. -FORCE_CONSISTENT flag.  However, this only flips the consistency bit and does
  42. not ensure that your data is consistent.  You would have to do that by hand.
  43.  
  44. >
  45. >
  46. > ------------------------------------------------------------------ 
  47. > Mark C. Jones (mcj@moose.cccs.umn.edu) 
  48. > CSC Partners
  49. > 5500 Wayzata Blvd, Suite 1100
  50. > Minneapolis  MN 55416  USA
  51. > +1 612 593 1122                   
  52. > ------------------------------------------------------------------ 
  53. >
  54.  
  55.  
  56. -- 
  57.  
  58. Steve Caswell           |   (404) 448-7727    |  "The opinions expressed are my
  59. Principal Consultant    |   sfc@tpghq.com     |   own.  They may not be perfect,
  60. The Palmer Group        |   uunet!tpghq!sfc   |   but they're all I've got."
  61.