home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / database / 9480 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  2.8 KB
  1. Xref: sparky comp.databases:9480 comp.object:5088 comp.databases.informix:3076
  2. Path: sparky!uunet!vnet.ibm.com
  3. From: pbenton@vnet.ibm.com
  4. Message-ID: <19930126.100713.257@almaden.ibm.com>
  5. Date: Tue, 26 Jan 93 09:09:45 PST
  6. Newsgroups: comp.databases,comp.object,comp.databases.informix
  7. Subject: Informix 4.0 and 4.1 questions (std engine)
  8. Lines: 59
  9.  
  10. Can anyone help with the following questions ?
  11.  
  12. We are running SCO UNIX version 3.2 with the Informix standard engine
  13. (ESQL/C version 4.01.UD2 and sqlexec version 4.01.UD2) on an
  14. Intel 386.
  15.  
  16. We have a process that once started, lives forever, periodically
  17. updating a database by INSERTs or UPDATEs.  For efficiency reasons,
  18. this process PREPAREs all the SQL statements during its
  19. initialization, and then later EXECUTEs the SQL statements to
  20. update the database.
  21.  
  22. Occasionally, its sqlexec child process terminates.  The parent
  23. process traps the SIGCLD (UNIX) signal and executes a siglongjmp()
  24. (UNIX system call) to recovery code (set up with the sigsetjmp()
  25. UNIX system call).  The recovery code includes calling sqlexit()
  26. and sqlstart() to clean up and start up a new sqlexec process.
  27. The database is then opened again.  However, when the process
  28. again PREPAREs all the SQL statements, Informix returns the error
  29. code -258 "System error--invalid statement ID received by the
  30. sqlexec process".  The process tries periodically to PREPARE the
  31. SQL statements until it's successful, but Informix continues to
  32. return the same error code.  Only in a few cases did Informix
  33. successfully PREPARE some (but not all) of the SQL statements
  34. after several attempts by the process.
  35.  
  36. *** Question:  What can we do to solve this problem ?
  37.                (Restarting the process is not an option.)
  38.  
  39.  
  40. Okay, back to the same process.  When it periodically saves data
  41. in the database, this process can be doing hundreds of INSERTs or
  42. UPDATEs.  To determine whether to do an INSERT or an UPDATE, the
  43. process first attempts to do an INSERT.  Following an INSERT, if
  44. the process detects a negative number in sqlca.sqlcode and the
  45. ISAM error code -100 (in sqlca.sqlerrd[1]), the process does the
  46. following:
  47.  
  48.    - SELECTs the existing entry from the database,
  49.    - combines the new data and the selected data, and
  50.    - UPDATEs the existing entry in the database with the combined data.
  51.  
  52. *** Questions:  Is this a good strategy to use ?
  53.                 If not, any suggestions ?
  54.  
  55.  
  56. The following problem exists with the above scenario ....
  57. Occasionally, when the process detects the existing entry and then
  58. tries to SELECT it, Informix returns SQLNOTFOUND.  When we manually
  59. query the database (using isql) for the existing entry, the so-called
  60. "existing" entry is not in the database !!
  61.  
  62. *** Question:  Why would this happen ?
  63.  
  64.  
  65. Any help would be very much appreciated.  Thank you.
  66.  
  67.  
  68. Pauline Benton (pbenton@vnet.ibm.com)
  69.