Benjamenus,
First, I am a DBA...I am not a dictator. I must have good business and technical reasons for implementing the structures I implement. I would be fascinated to hear your DBA's rationale for using LONG versus CLOB.
Here are some questions (which answers I would enjoy hearing) that you can pose to your DBA regarding the use of LONGs:
Q1) What are the advantages of using LONG that prevent our using CLOB in our application(s)?
My A1) There are none. LONG columns are similar to the character Lennie in John Steinbeck's classic, "Of Mice and Men"...Big and hopelessly functionally retarded. You
cannot do any data manipulation to a LONG; you cannot query a LONG in concert with other columns. With CLOB, you
can do all types of data manipulation that is typical with a VARCHAR2 column.
Q2) What are the disadvantages or risks of converting from a LONG column to a CLOB.
My A2) There are none. Oracle allows "ALTER TABLE <name> MODIFY <LONG-column> CLOB;" without incident. The disadvantages/risks of remaining with LONG columns are that you must come up with some very convoluted method of trying to "turn Lennie into a college graduate". There are
tons of business risks to your trying to contrive normal functionality for LONGs. I know, because I've had to attempt that project on old versions of Oracle that lack CLOB functionality. The solution was a programmatical hodge-podge with
very limited success for the 4K/32K limitations that you, Parbhani, and Turkbear already presented, above.
So, all-in-all, your DBAs should have much better overriding business/technical reasons for restricting you to the use of LONGS (versus CLOB) than the lame (but typical) reason: "Because we said so." In this case, there is proof that remaining with LONG (versus CLOB) can be a costly business/technical decision.
![[santa] [santa] [santa]](/data/assets/smilies/santa.gif)
Mufasa
(aka Dave of Sandy, Utah, USA @ 15:52 (10Jun04) UTC (aka "GMT" and "Zulu"), 08:52 (10Jun04) Mountain Time)