home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / next / bugs / 13 < prev    next >
Encoding:
Internet Message Format  |  1992-12-31  |  3.3 KB
  1. Xref: sparky comp.sys.next.bugs:13 comp.sys.next.programmer:7957
  2. Newsgroups: comp.sys.next.bugs,comp.sys.next.programmer
  3. Path: sparky!uunet!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!wupost!eclnews!usenet
  4. From: mrb@earth.wustl.edu (Mike Bray)
  5. Subject: help needed:  dbkit and/or oracle adaptor bug
  6. Message-ID: <1992Dec31.192359.22612@wuecl.wustl.edu>
  7. Sender: usenet@wuecl.wustl.edu (News Administrator)
  8. Nntp-Posting-Host: earth
  9. Organization: Washington University, St. Louis MO
  10. Date: Thu, 31 Dec 1992 19:23:59 GMT
  11. Lines: 62
  12.  
  13. DBKit - Oracle Adapter Bug
  14.  
  15. There are two, possibly related, problems with the DBDatabase delegate 
  16. "db:notificationFrom:message:code".  I am in great need of a work around for 
  17. problem #1.
  18.  
  19. 1.  When doing a fetch, and Oracle discovers an error during the parse phase, 
  20. db:notificationFrom:message:code generally returns the proper error code (see 
  21. #2 below for a time when it doesn't).  If an error occurs during the fetch 
  22. phase, no notificationFrom: message is generated, and the "db:log:" delegate 
  23. prints the message "selectData:  succeeded".  However, no data is available, 
  24. and dependent display objects show blanks.  This is very bad, because I need 
  25. access to Oracle's error number.
  26.  
  27. Here's an example that works properly:
  28.  
  29. From SQL*DBA, "select garbage_column_name from dual" correctly returns:
  30. ORA-00904:  invalid column name
  31.  
  32. Creating a DBExpression with the string "garbage_column_name" and then 
  33. fetching it causes the notificationFrom delegate to be called, yielding the 
  34. proper error code number, -904.
  35.  
  36. Now for the example that doesn't work right:
  37.  
  38. From SQL*DBA, "select to_date('asdf') from dual" returns:
  39.  
  40. TO_DATE('
  41. ---------
  42. ORA-01858:  a letter was found in a date where a number was expected
  43.  
  44. This is proper behavior.  Notice that a column heading was printed, 
  45. "TO_DATE('",
  46. indicating that the statement parsed ok, but Oracle found an error during the 
  47. evaluation of the statement.  This differs from the first example, where no 
  48. column heading is printed, since it doesn't get as far through the 
  49. parse/evaluation process.
  50.  
  51. Creating a DBExpression with the string "to_date('asdf')" and then fetching it 
  52. DOES NOT generate a notificationFrom: event.  This is a major problem.  
  53. Watching the results of "db:log:", a "selectData:  succeeded" message goes by, 
  54. but the number of records fetched is zero.  Checking for zero is the only 
  55. indication we have that an error occurred.  
  56.  
  57. How can I get the error message from Oracle?  I'm assuming that this bug is 
  58. some problem in interpreting the error codes returned by Oracle OCI.  I really 
  59. need some sort of work around for this problem.
  60.  
  61.  
  62. 2.  When attempting to insert a duplicate value into an index defined as 
  63. unique, 
  64. oracle version 6 generates "ORA-00001:  duplicate key in index", which is the 
  65. proper code.  When attempted through DBKit, the notificationFrom: code is 9, 
  66. which is not a valid V6 error number.  However, consulting the Oracle OCI 
  67. manual, the value 9 is the value returned by Oracle Version 2!  It is still 
  68. provided for backward compatibility in the OCI cursor data area, called the V2 
  69. Return Code.  Is this somehow being accessed by mistake?  I can work around 
  70. this problem, since it consistently returns the same value, but it seems that 
  71. this might be a problem related to #1 above.
  72.  
  73. Thanks,
  74. Mike Bray  307-332-6973 x279
  75.