On Sep 23, 11:36*am, "Gerard H. Pille" <g... (AT) skynet (DOT) be> wrote:

4k? What is the use of CLOB if it can only handle 4k, make it a
VARCHAR2? That makes no sense.

A stored procedure should be able to receive a CLOB and store it in a
CLOB column. Heck, think of the articles on CNN and other sites. Do
you think they are only 4k? Most images are greater than 4k also.

On 2010-09-23 16:59, The Magnet <art (AT) unsu (DOT) com> wrote:
A CLOB can be up to 4 GB, but you cannot access it as a whole from SQL
(or PL/SQL). You can only read and write it in chunks of a few kB at a
time. Some drivers (e.g. the DBD::Oracle driver for Perl) do that behind
the scenes so that it looks like you can just insert/update/select a
LOB, I don't know about the PHP driver. If it doesn't give you a
convenient way to access LOBs, you take a look at the DBMS_LOB package.

hp

The Magnet wrote:

Why don't you crawl back under your stone?

On Sep 23, 2:43*pm, "Gerard H. Pille" <g... (AT) skynet (DOT) be> wrote:
I see you forgot to take your medication today.

The Magnet wrote:
And what are you lacking? Only a troll will "mistake" SQL for CLOB.

If you want and are able to read someone else's confirmation:

http://philip.greenspun.com/sql/limits.html

The Magnet <art (AT) unsu (DOT) com> writes:

Ask yourself this simple question.

If all clob processing could be handled by simple SQL from within
PL/SQL, why would they provide a special pl/sql package for manipulating
blobs/clobs?

Highly recommend you read the developers guide section on working with
large objects. In particular, note the sections about the differences
between clob locators and data, the impact of opening and closing clob
locators, the importance of locking rows that need to e updated i.e.
select for update etc.

Tim




--
tcross (at) rapttech dot com dot au

Since this thread is read by serious people too:

today one of our developers ran into "not enough space" when filling a table with a lob column.

He didn't understand how this happened, he had no way entered enough data to fill the tablespace.

I checked, and the lobsegment was taking 240Mb for some 60Mb of data (sum(dbms_lob.getlength()).
I moved the lobsegment to another tablespace, and doing so the segment shrank to 100Mb.

What should I do to prevent this waste of space?

Thanks,

Gerard

On Sep 29, 9:37*am, "Gerard H. Pille" <g... (AT) skynet (DOT) be> wrote:
There have been discussions in various places about this, I don't have
time to find the relevant ones, but here's a start:

http://jonathanlewis.wordpress.com/2...11/lob-sizing/
MOS How to determine the actual size of the LOB segments and how to
free the deleted/unused space above/below the HWM [ID 386341.1]

Usual caveats about information from the intertubes apply.

jg
--
@home.com is bogus.
"Only amateurs attack machines; professionals target people." - Bruce
Schneier, as quoted in http://catless.ncl.ac.uk/Risks/26.17.html#subj13

joel garry wrote:
So my getlength on a UTF8 database could be missing half the bytes, and I need to get rid of
ASSM (see my thread in c.d.o.s).