Re: Copying rows with LONG RAW field to another database

A copy of this was sent to sinkiege_at_tiac.net (Gerry Sinkiewicz) (if that email address didn't require changing) On Thu, 03 Sep 98 00:33:40 GMT, you wrote:

>In article <6ska6c$iqr$1_at_snoopy.ndcorp.com>, ndcdba_at_mindspring.com wrote:
>>Jason.Ford_at_msfc.nasa.gov (Jason Ford) wrote:
>>
>>>I believe this will only work for long raw data with a length of 32760
>>>bytes or less.
>>
>>Yes. I'm used to only requiring a few thousand bytes for my BLOBs.
>>Sorry.
>>
>
>Just today one of my customers mentioned that he was designing a table
>for which I was going to set up a schema and tablespaces and that would
>contain digitized blueprints (LONG RAW). So knowing that export had
>a problem with long raw I decided to read about it. Truncation at 64K will
>occur at export time.
>

where did you read that? I frequently export/import muli-megabyte long raws without issue.

You must set the BUFFER= parameter but it works without issue.

>So If you need to copy long raw it it time to write an unload pgm and use
>sql*loader to put it back.
>I was happy to hear that they would not be needing me to copy their long raw
>data to production, but our full exports will be a problem in the future.
>

they shouldn't -- set buffer=<some big number> and it'll work. I've moved many many meg of images from one database to another using exp/imp and they were way over 64k.

sounds like a v6 limit to me -- v6 had a limit of 64k on LONGS and LONG RAWS.

>Gerald P. Sinkiewicz
>E-mail sinkiege_at_tiac.net
 

Thomas Kyte
tkyte_at_us.oracle.com
Oracle Government
Herndon VA

--
http://govt.us.oracle.com/    -- downloadable utilities
 
----------------------------------------------------------------------------
Opinions are mine and do not necessarily reflect those of Oracle Corporation
 
Anti-Anti Spam Msg: if you want an answer emailed to you, 
you have to make it easy to get email to you.  Any bounced
email will be treated the same way i treat SPAM-- I delete it.