home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / next / bugs / 11 < prev    next >
Encoding:
Internet Message Format  |  1992-12-30  |  2.2 KB
  1. Xref: sparky comp.sys.next.bugs:11 comp.sys.next.programmer:7945 comp.databases.oracle:2656
  2. Newsgroups: comp.sys.next.bugs,comp.sys.next.programmer,comp.databases.oracle
  3. Path: sparky!uunet!wupost!eclnews!usenet
  4. From: mrb@earth.wustl.edu (Mike Bray)
  5. Subject: Two DBKit bugs - help me find fixes please
  6. Message-ID: <1992Dec30.045835.24679@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: Wed, 30 Dec 1992 04:58:35 GMT
  11. Lines: 32
  12.  
  13. I'm running NextStep 3.0 (gold) on a Turbo Color NeXTStation, and 
  14. Oracle 6.0.33.2.1.
  15.  
  16. 1.  I have discovered a problem with DBExpressions that I haven't seen 
  17. described anywhere yet.  I'm using the Oracle adaptor.  I create a DBExpression 
  18. with the following description:  "select sysdate from dual".  Executing a fetch 
  19. and displaying the results gives me GMT time.  Executing the same SQL statement 
  20. from SQL*DBA, the Oracle administration tool gives me local time, as I expect, 
  21. and need.  I suspect there's a problem with an environment variable or dwrite 
  22. that is used to tell the MACH kernel what time to return.  Oracle Tech 
  23. Support hasn't been able to tell me just what Oracle does to get the time, and 
  24. I'm totally confused about how the NeXT does time localization.
  25.  
  26. I need a workaround of some sort.  Merely subtracting 7 hours from the GMT time 
  27. doesn't allow for semi-annual daylight time shifts.
  28.  
  29. 2.  Using the same DBExpression scheme as described above, but this time using 
  30. the string "select to_char(sysdate,'HH:MI:SS') from dual" causes the program to 
  31. crash.  I isolated the problem to the presence of the colon in the format 
  32. string.  Substituting a period for the colon resulted in the proper response.  
  33. I'm guessing that DBKit or the Oracle adaptor use an OCI call such as "osql3" 
  34. and doesn't properly parse colons inside quotes, treating them like bind 
  35. variables by mistake.  For a workaround, I'm resigned to using periods and then 
  36. doing a character substitution on the result string to get the time format I 
  37. want.
  38.  
  39. Question:  What version of Oracle OCI was used in the Oracle Adaptor?
  40.  
  41. Thanks,
  42. Mike Bray 
  43. mrb@earth.wustl.edu
  44. 307-332-6973 x279
  45.