Not a dumb question at all. I think the answer is simply the string
length limit of PL/SQL.
In general with CLOB's, you have to deal with the physical realities
of limits in the db. It's harder to just make everything logical like
you theoretically should be able to with relational databases. So
physical limits are worked around by hiding in packages, or hiding the
realities in other languages.
jg
--
@home.com is bogus.
http://www.cracked.com/photoshop_90_the-world-tomorrow-if-internet-disappeared-today_p19
: This may be a dumb question, but why can't Oracle read anything
: greater than 32767?? Even CLOB's? You really have to loop and do
: some crappy stuff??
What are you trying to do? I often use perl + DBI, and doing simple
inserts and selects of clobs (from/into bind variables mapped to perl
varables) requires no special handling, though you may need to set
LongReadLen ahead of time.
How are you trying to read the LOB? The sqlldr utility can read LOB's
over 32K. Now the utl_file utility used to have a 32K record size
limit in it. Are you using it?
What full version of Oracle? Oracle capabilities for dealing with LOB
data has evolved over the releases since 8.0 introdduced the data
type.
HTH -- Mark D Powell --
The answer is that it can read. I used DBMS_LOB.READ to read the entire
1MB and that was in version 9i. The problem is that I was using C
language. What are you using?
The answer is that it can read. I used DBMS_LOB.READ to read the entire
We are using PHP to perform the actual call to the DB. My solution
was to return 2 variables, breaking the CLOB up and having PHP receive
2 output values.
Still, a dumb limitation. You'd think by this point Oracle would have
fixed that.
I have no problem reading large CLOBs using JDBC....
Thomas
: We are using PHP to perform the actual call to the DB. My solution
: was to return 2 variables, breaking the CLOB up and having PHP receive
: 2 output values.
: Still, a dumb limitation. You'd think by this point Oracle would have
: fixed that.
First ask yourself what would happen to your php script if you read the
entire clob into a single variable - and the clob was (for example) 4
gigabytes in size. What portion of the software should handle that?
Should the Oracle networking return that as a single data item to the
application's oracle interface? Should the interface handle that so your
application doesn't see it? Should your application handle it itself?
I think it is obvious that the oracle networking should not return that as
a single item because then virtually no application or interface could
ever be sure of being able to handle clob data. That leaves the interface
or the application. As I mentioned earlier, I often use perl because the
DBI interface handles that issue so my applicaiton doesn't have to. From
other posts, it sounds like various other interfaces also handle the
issue.
As for php, my reading of the php documentation of OCI-Lob->load says it
can read any size up to "memory_limit", which appears to be set in
php.ini, though it is also limited by the compile time options of your php
executable. So perhaps the issue is the setup of the php you are using.
$0.10
Have you tried posting the code on the OTN PHP forum? Chris Jones and some
other guys might be able to help you out.
Have you tried posting the code on the OTN PHP forum? Chris Jones and some
I do not think it is an Oracle limitation. Other tools as posted can
retrieve the entire lob at once, or at least larger LOB chunks. I
think researching the other suggestions and referring to whatever PHP
to Oracle documentation you can find is the next step.