home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / database / oracle / 2168 < prev    next >
Encoding:
Internet Message Format  |  1992-11-10  |  1.7 KB
  1. Path: sparky!uunet!oracle!unrepliable!bounce
  2. Newsgroups: comp.databases.oracle
  3. From: rhari@us.oracle.com
  4. Subject: Re: Eating it RAW
  5. Message-ID: <1992Nov10.151345.1@us.oracle.com>
  6. Lines: 30
  7. Sender: usenet@oracle.us.oracle.com (Oracle News Poster)
  8. Nntp-Posting-Host: kervms.us.oracle.com
  9. Organization: Oracle Corporation, USA
  10. References: <BxGJw1.Kr1@well.sf.ca.us>
  11. Distribution: usa
  12. Date: Tue, 10 Nov 1992 23:13:45 GMT
  13. X-Disclaimer: This message was written by an unauthenticated user
  14.               at Oracle Corporation.  The opinions expressed are those
  15.               of the user and not necessarily those of Oracle.
  16.  
  17. In article <BxGJw1.Kr1@well.sf.ca.us>, mharper@well.sf.ca.us (Michael J. Harper) writes:
  18. > I am trying to store data into a LONG RAW column, and I am running into
  19. > some difficulty.
  20. > 
  21. > The data I would like to store happens to be TIFF data.  Consequently, it
  22. > is a minimum of 4K or so in size.  When I tried using HEXTORAW with an 8K
  23. > string, I was told that my string was too long.  So, I divided the string
  24. > into a bunch of 254-character strings all concatenated.  No parse error,
  25. > but only the first 256 characters were stored anyway.  This gives me only
  26. > 128 bytes of raw data, which isn't quite enough.
  27. > 
  28. > So, is there another way to issue an INSERT that will allow me to store up to
  29. > the full length of my LONG RAW?  
  30. > 
  31. > Also, I noticed that when I fetch this column, the first byte seems to be 
  32. > the row number in the query.  Does anyone know what this byte really means 
  33. > and what it's doing at the beginning of my raw data?
  34. > 
  35. > Thanks.
  36. > -- 
  37. > Michael J. Harper
  38. > mharper@well.sf.ca.us
  39. -- 
  40. I presume you are using version 6 of ORACLE.
  41.  
  42. The best way to handle raw data is thru OCI or Pro* languages.
  43.  
  44.  
  45. Radhakrishna Hari
  46. rhari@us.oracle.com
  47.