CLOBS - Access2000 to Oracle8i

Hi there,
I'm migrating an ACCESS2000-DB to Oracle 8i using an ODBC connection for the ACCESS-DB.
I wrote a SQL*PLUS script which uses the COPY command to import the data into oracle-db since the db-design in oracle does not match exactly to the access-db (-> redesign). This works very well, even for ACCESS-memo-fields converted to oracle-clobs. But I get an error message (ORA-00932: inconsistent datatypes) when I try to import a table with 2 or more CLOB-columns. I know the COPY command only supports 1 LONG column per statement, so I tried to fill the second CLOB per update from a temp. table. But it didn't work as well.
Any comments would be appreciated.
Regards
null

You should be able to use the gateway products for this. Take a look at http://otn.oracle.com/products/gateways/content.html.
Thanks,
Danny

Similar Messages

From access2000 to oracle8.17

How to migrate a DB (table/query) from access2000 to oracle 8.17 ?
Does an 'official' toolkit Oracle exist?

Yes,
you can download OMWB (Oracle Migration Work Bench) from Oracle Web.
Click on gray Software tab on the current (i presume !) page, then choose to download omwb.
Regards
Pascal

ORACLE8I - LONG TYPE을 LOB TYPE으로 CONVERSION하는 방법(TO_LOB)

제품 : ORACLE SERVER
작성날짜 : 2002-04-12
ORACLE8I - LONG TYPE을 LOB TYPE으로 CONVERSION하는 방법(TO_LOB)
===============================================================
Purpose
Long type의 data를 lob type으로 conversion하는 to_lob function에 대해
알아보자.
Explanation
Oracle8 부터 long 이나 long raw type과는 별도로 lob type이 추가되었다.
long 이나 long raw type을 clob 또는 blob type으로 변경하기 위해서는
Oracle8 에서는 데이타를 다시 입력해야 했지만, Oracle8i 에서는 추가된
TO_LOB function을 이용하여 간단히 data migration을 할 수 있다.
TO_LOB function은 보통 create table .. as select .. 문장이나
insert into .. select .. 문장에서 쉽게 사용할 수 있다.
Example
[예제1] long type의 데이타를 clob type으로 옮기는 방법
아래의 예제에서 type만 long raw와 blob 로 바꾸어도 가능하다.
SQL> create table long_data (c1 number, c2 long);
Table created.
SQL> desc long_data
Name Null? Type
C1 NUMBER
C2 LONG
SQL> insert into long_data values
2 (1, 'This is some long data to be migrated to a CLOB');
1 row created.
SQL> create table test_lobs
2 (c1 number, c2 clob);
Table created.
SQL> desc test_lobs
Name Null? Type
C1 NUMBER
C2 CLOB
SQL> insert into test_lobs
2 select c1, to_lob(c2) from long_data;
1 row created.
SQL> select c2 from test_lobs;
C2
This is some long data to be migrated to a CLOB
[예제2] long type을 clob type으로 바꾸어 table 생성하는 방법
SQL> create table clob_data
2 as select c1, to_lob(c2) c2 from long_data;
Table created.
SQL> desc clob_data
Name Null? Type
C1 NUMBER
C2 CLOB
[예제3] long raw type을 blob type으로 바꾸어 table 생성하는 방법
SQL> desc image_data
Name Null? Type
C1 NUMBER
C2 LONG RAW
SQL> create table blob_data
2 as select c1, to_lob(c2) c2 from image_data;
Table created.
SQL> desc blob_data
Name Null? Type
C1 NUMBER
C2 BLOB

You may not insert LONGs into a table that are selected from a remote database. You can simply SELECT LONGs across a DB link, but you just can't INSERT... SELECT them.
Greg Pike
http://www.singlequery.com

Convert UTF8 clob charset

Thanks for your advice.
Actually NLS support may not apply to my case because I need to specify different charset when I need the CLOB UTF8 data from my database. Maybe this time I need Big5, next time I need GBK. The thing is, I know there is a function to convert varchar2 from UTF8 to different charset.
Question is: can I convert CLOB as well?
Thanks for any advice!

There are no SQL convert functions to handle CLOB conversion in Oracle8i . In 9i all SQL functions for VARCHAR2 will work with CLOBs too.
Why do you need to have do the conversion explicitly, if you set your client NLS_LANG character set to ZHT16BIG5 or ZHT16GBK , they these CLOBs should be converted to the client Character set automatically.

Change character set

Hi
is anyone can tell me how to change characterset.
i try with alter session but it doesnt work.
thanks

Article from Metalink
Doc ID: Note:66320.1
Subject: Changing the Database Character Set or the Database National Character Set
Type: BULLETIN
Status: PUBLISHED
 Content Type: TEXT/PLAIN
Creation Date: 23-OCT-1998
Last Revision Date: 12-DEC-2003
PURPOSE ======= To explain how to change the database character set or national character set of an existing Oracle8(i) or Oracle9i database without having to recreate the database. 1. SCOPE & APPLICATION ====================== The method described here is documented in the Oracle 8.1.x and Oracle9i documentation. It is not documented but it can be used in version 8.0.x. It does not work in Oracle7. The database character set is the character set of CHAR, VARCHAR2, LONG, and CLOB data stored in the database columns, and of SQL and PL/SQL text stored in the Data Dictionary. The national character set is the character set of NCHAR, NVARCHAR2, and NCLOB data. In certain database configurations the CLOB and NCLOB data are stored in the fixed-width Unicode encoding UCS-2. If you are using CLOB or NCLOB please make sure you read section "4. HANDLING CLOB AND NCLOB COLUMNS" below in this document. Before changing the character set of a database make sure you understand how Oracle deals with character sets. Before proceeding please refer to [NOTE:158577.1] "NLS_LANG Explained (How Does Client-Server Character Conversion Work?)". See also [NOTE:225912.1] "Changing the Database Character Set - an Overview" for general discussion about various methods of migration to a different database character set. If you are migrating an Oracle Applications instance, read [NOTE:124721.1] "Migrating an Applications Installation to a New Character Set" for specific steps that have to be performed. If you are migrating from 8.x to 9.x please have a look at [NOTE:140014.1] "ALERT: Oracle8/8i to Oracle9i Using New "AL16UTF16"" and other referenced notes below. Before using the method described in this note it is essential to do a full backup of the database and to use the Character Set Scanner utility to check your data. See the section "2. USING THE CHARACTER SET SCANNER" below. Note that changing the database or the national character set as described in this document does not change the actual character codes, it only changes the character set declaration. If you want to convert the contents of the database (character codes) from one character set to another you must use the Oracle Export and Import utilities. This is needed, for example, if the source character set is not a binary subset of the target character set, i.e. if a character exists in the source and in the target character set but not with the same binary code. All binary subset-superset relationships between characters sets recognized by the Oracle Server are listed in [NOTE:119164.1] "Changing Database Character Set - Valid Superset Definitions". Note: The varying width character sets (like UTF8) are not supported as national character sets in Oracle8(i) (see [NOTE:62107.1]). Thus, changing the national character set from a fixed width character set to a varying width character set is not supported in Oracle8(i). NCHAR types in Oracle8 and Oracle8i were designed to support special Oracle specific fixed-width Asian character sets, that were introduced to provide higher performance processing of Asian character data. Examples of these character sets are : JA16EUCFIXED ,JA16SJISFIXED , ZHT32EUCFIXED. For a definition of varying width character sets see also section "4. HANDLING CLOB AND NCLOB COLUMNS" below. WARNING: Do not use any undocumented Oracle7 method to change the database character set of an Oracle8(i) or Oracle9i database. This will corrupt the database. 2. USING THE CHARACTER SET SCANNER ================================== Character data in the Oracle 8.1.6 and later database versions can be efficiently checked for possible character set migration problems with help of the Character Set Scanner utility. This utility is included in the Oracle Server 8.1.7 software distribution and the newest Character Set Scanner version can be downloaded from the Oracle Technology Network site, http://otn.oracle.com The Character Set Scanner on OTN is available for limited number of platforms only but it can be used with databases on other platforms in the client/server configuration -- as long as the database version matches the Character Set Scanner version and platforms are either both ASCII-based or both EBCDIC-based. It is recommended to use the newest Character Set Scanner version available from the OTN site. The Character Set Scanner is documented in the following manuals: - "Oracle8i Documentation Addendum, Release 3 (8.1.7)", Chapter 3 - "Oracle9i Globalization Support Guide, Release 1 (9.0.1)", Chapter 10 - "Oracle9i Database Globalization Support Guide, Release 2 (9.2)", Chapter 11 Note: The Character Set Scanner coming with Oracle 8.1.7 and Oracle 9.0.1 does not have a separate version number. It reports the database release number in its banner. This version of the Scanner does not check for illegal character codes in a database if the FROMCHAR and TOCHAR (or FROMNCHAR and TONCHAR) parameters have the same value (i.e. you simulate migration from a character set to itself). The Character Set Scanner 1.0, available on OTN, reports its version number as x.x.x.1.0, where x.x.x is the database version number. This version adds a few bug fixes and it supports FROMCHAR=TOCHAR provided it is not UTF8. The Character Set Scanner 1.1, available on OTN and with Release 2 (9.2) of the Oracle Server, reports its version number as v1.1 followed by the database version number. This version adds another bug fixes and the full support for FROMCHAR=TOCHAR. None of the above versions of the Scanner can correctly analyze CLOB or NCLOB values if the database or the national character set, respectively, is multibyte. The Scanner reports such values randomly as Convertible or Lossy. The version 1.2 of the Scanner will mark all such values as Changeless (as they are always stored in the Unicode UCS-2 encoding and thus they do not change when the database or national character set is changed from one multibyte to another). Character Set Scanner 2.0 will correctly check CLOBs and NCLOBs for possible data loss when migrating from a multibyte character set to its subset. To verify that your database contains only valid codes, specify the new database character set in the TOCHAR parameter and/or the new national character set in the TONCHAR parameter. Specify FULL=Y to scan the whole database. Set ARRAY and PROCESS parameters depending on your system's resources to speed up the scanning. FROMCHAR and FROMNCHAR will default to the original database and national character sets. The Character Set Scanner should report only Changless data in both the Data Dictionary and in application data. If any Convertible or Exceptional data are reported, the ALTER DATABASE [NATIONAL] CHARACTER SET statement must not be used without further investigation of the source and type of these data. In situations in which the ALTER DATABASE [NATIONAL] CHARACTER SET statement is used to repair an incorrect database character set declaration rather than to simply migrate to a new wider character set, you may be advised by Oracle Support Services analysts to execute the statement even if Exceptional data are reported. For more information see also [NOTE:225912.1] "Changing the Database Character Set - a short Overview". 3. CHANGING THE DATABASE OR THE NATIONAL CHARACTER SET ====================================================== Oracle8(i) introduces a new documented method of changing the database and national character sets. The method uses two SQL statements, which are described in the Oracle8i National Language Support Guide: ALTER DATABASE [<db_name>] CHARACTER SET <new_character_set> ALTER DATABASE [<db_name>] NATIONAL CHARACTER SET <new_NCHAR_character_set> The database name is optional. The character set name should be specified without quotes, for example: ALTER DATABASE CHARACTER SET WE8ISO8859P1 To change the database character set perform the following steps. Note that some of them have been erroneously omitted from the Oracle8i documentation: 1. Use the Character Set Scanner utility to verify that your database contains only valid character codes -- see "2. USING THE CHARACTER SET SCANNER" above. 2. If necessary, prepare CLOB columns for the character set change -- see "4. HANDLING CLOB AND NCLOB COLUMNS" below. Omitting this step can lead to corrupted CLOB/NCLOB values in the database. If SYS.METASTYLESHEET (STYLESHEET) is populated (9i and up only) then see [NOTE:213015.1] "SYS.METASTYLESHEET marked as having convertible data (ORA-12716 when trying to convert character set)" for the actions that need to be taken. 3. Make sure the parallel_server parameter in INIT.ORA is set to false or it is not set at all. 4. Execute the following commands in Server Manager (Oracle8) or sqlplus (Oracle9), connected as INTERNAL or "/ AS SYSDBA": SHUTDOWN IMMEDIATE; -- or NORMAL <do a full database backup> STARTUP MOUNT; ALTER SYSTEM ENABLE RESTRICTED SESSION; ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0; ALTER SYSTEM SET AQ_TM_PROCESSES=0; ALTER DATABASE OPEN; ALTER DATABASE CHARACTER SET <new_character_set>; SHUTDOWN IMMEDIATE; -- OR NORMAL STARTUP RESTRICT; 5. Restore the parallel_server parameter in INIT.ORA, if necessary. 6. Execute the following commands: SHUTDOWN IMMEDIATE; -- OR NORMAL STARTUP; The double restart is necessary in Oracle8(i) because of a SGA initialization bug, fixed in Oracle9i. 7. If necessary, restore CLOB columns -- see "4. HANDLING CLOB AND NCLOB COLUMNS" below. To change the national character set replace the ALTER DATABASE CHARACTER SET statement with ALTER DATABASE NATIONAL CHARACTER SET. You can issue both statements together if you wish. Error Conditions ---------------- A number of error conditions may be reported when trying to change the database or national character set. In Oracle8(i) the ALTER DATABASE [NATIONAL] CHARACTER SET statement will return: ORA-01679: database must be mounted EXCLUSIVE and not open to activate - if you do not enable restricted session - if you startup the instance in PARALLEL/SHARED mode - if you do not set the number of queue processes to 0 - if you do not set the number of AQ time manager processes to 0 - if anybody is logged in apart from you. This error message is misleading. The command requires the database to be open but only one session, the one executing the command, is allowed. For the above error conditions Oracle9i will report one of the errors: ORA-12719: operation requires database is in RESTRICTED mode ORA-12720: operation requires database is in EXCLUSIVE mode ORA-12721: operation cannot execute when other sessions are active Oracle9i can also report: ORA-12718: operation requires connection as SYS if you are not connect as SYS (INTERNAL, "/ AS SYSDBA"). If the specified new character set name is not recognized, Oracle will report one of the errors: ORA-24329: invalid character set identifier ORA-12714: invalid national character set specified ORA-12715: invalid character set specified The ALTER DATABASE [NATIONAL] CHARACTER SET command will only work if the old character set is considered a binary subset of the new character set. Oracle Server 8.0.3 to 8.1.5 recognizes US7ASCII as the binary subset of all ASCII-based character sets. It also treats each character set as a binary subset of itself. No other combinations are recognized. Newer Oracle Server versions recognize additional subset/superset combinations, which are listed in [NOTE:119164.1]. If the old character set is not recognized as a binary subset of the new character set, the ALTER DATABASE [NATIONAL] CHARACTER SET statement will return: - in Oracle 8.1.5 and above: ORA-12712: new character set must be a superset of old character set - in Oracle 8.0.5 and 8.0.6: ORA-12710: new character set must be a superset of old character set - in Oracle 8.0.3 and 8.0.4: ORA-24329: invalid character set identifier You will also get these errors if you try to change the characterset of a US7ASCII database that was started without a (correct) ORA_NLSxx parameter. See [NOTE:77442.1] It may be necessary to switch off the superset check to allow changes between formally incompatible character sets to solve certain character set problems or to speed up migration of huge databases. Oracle Support Services may pass the necessary information to customers after verifying the safety of the change for the customers' environments. If in Oracle9i an ALTER DATABASE NATIONAL CHARACTER SET is issued and there are N-type colums who contain data then this error is returned: ORA-12717:Cannot ALTER DATABASE NATIONAL CHARACTER SET when NCLOB data exists The error only speaks about Nclob but Nchar and Nvarchar2 are also checked see [NOTE:2310895.9] for bug [BUG:2310895] 4. HANDLING CLOB AND NCLOB COLUMNS ================================== Background ---------- In a fixed width character set codes of all characters have the same number of bytes. Fixed width character sets are: all single-byte character sets and those multibyte character sets which have names ending with 'FIXED'. In Oracle9i the character set AL16UTF16 is also fixed width. In a varying width character set codes of different characters may have different number of bytes. All multibyte character sets except those with names ending with FIXED (and except Oracle9i AL16UTF16 character set) are varying width. Single-byte character sets are character sets with names of the form xxx7yyyyyy and xxx8yyyyyy. Each character code of a single-byte character set occupies exactly one byte. Multibyte character sets are all other character sets (including UTF8). Some -- usually most -- character codes of a multibyte character set occupy more than one byte. CLOB values in a database whose database character set is fixed width are stored in this character set. CLOB values in an Oracle 8.0.x database whose database character set is varying width are not allowed. They have to be NULL. CLOB values in an Oracle >= 8.1.5 database whose database character set is varying width are stored in the fixed width Unicode UCS-2 encoding. The same holds for NCLOB values and the national character set. The UCS-2 storage format of character LOB values, as implemented in Oracle8i, ensures that calculation of character positions in LOB values is fast. Finding the byte offset of a character stored in a varying width character set would require reading the whole LOB value up to this character (possibly 4GB). In the fixed width character sets the byte offsets are simply character offsets multiplied by the number of bytes in a character code. In UCS-2 byte offsets are simply twice the character offsets. As the Unicode character set contains all characters defined in any other Oracle character set, there is no data loss when a CLOB/NCLOB value is converted to UCS-2 from the character set in which it was provided by a client program (usually the NLS_LANG character set). CLOB Values and the Database Character Set Change ------------------------------------------------- In Oracle 8.0.x CLOB values are invalid in varying width character sets. Thus you must delete all CLOB column values before changing the database character set to a varying width character set. In Oracle 8.1.5 and later CLOB values are valid in varying width character sets but they are converted to Unicode UCS-2 before being stored. But UCS-2 encoding is not a binary superset of any other Oracle character set. Even codes of the basic ASCII characters are different, e.g. single-byte code for "A"=0x41 becomes two-byte code 0x0041. This implies that even if the new varying width character set is a binary superset of the old fixed width character set and thus VARCHAR2/LONG character codes remain valid, the fixed width character codes in CLOB values will not longer be valid in UCS-2. As mentioned above, the ALTER DATABASE [NATIONAL] CHARACTER SET statement does not change character codes. Thus, before changing a fixed width database character set to a varying width character set (like UTF8) in Oracle 8.1.5 or later, you first have to export all tables containing non-NULL CLOB columns, then truncate these tables, then change the database character set and, finally, import the tables back to the database. The import step will perform the required conversion. If you omit the steps above, the character set change will succeed in Oracle8(i) (Oracle9i disallows the change in such situation) and the CLOBs may appear to be correctly legible but as their encoding is incorrect, they will cause problems in further operations. For example, CREATE TABLE AS SELECT will not correctly copy such CLOB columns. Also, after installation of the 8.1.7.3 server patchset the CLOB columns will not longer be legible. LONG columns are always stored in the database character set and thus they behave like CHAR/VARCHAR2 in respect to the character set change. BLOBs and BFILEs are binary raw datatypes and their processing does not depend on any Oracle character set setting. NCLOB Values and the National Character Set Change -------------------------------------------------- The above discussion about changing the database character set and exporting and importing CLOB values is theoretically applicable to the change of the national character set and to NCLOB values. But as varying width character sets are not supported as national character sets in Oracle8(i), changing the national character set from a fixed width character set to a varying width character set is not supported at all. Preparing CLOB Columns for the Character Set Change --------------------------------------------------- Take a backup of the database. If using Advanced Replication or deferred transactions functionality, make sure that there are no outstanding deferred transactions with CLOB parameters, i.e. DEFLOB view must have no rows with non-NULL CLOB_COL column; to make sure that replication environment remains consistent use only recommended methods of purging deferred transaction queue, preferably quiescing the replication environment. Then: - If changing the database character set from a fixed width character set to a varying with character set in Oracle 8.0.x, set all CLOB column values to NULL -- you are not allowed to use CLOB columns after the character set change. - If changing the database character set from a fixed width character set to a varying width character set in Oracle 8.1.5 or later, perform table-level export of all tables containing CLOB columns, including SYSTEM's tables. Set NLS_LANG to the old database character set for the Export utility. Then truncate these tables. Restoring CLOB Columns after the Character Set Change ----------------------------------------------------- In Oracle 8.1.5 or later, after changing the character set as described above (steps 3. to 6.), restore CLOB columns exported in step 2. by importing them back into the database. Set NLS_LANG to the old database character set for the Import utility to avoid IMP-16 errors and data loss. RELATED DOCUMENTS: ================== [NOTE:13856.1] V7: Changing the Database Character Set -- This note has limited distribution, please contact Oracle Support [NOTE:62107.1] The National Character Set in Oracle8 [NOTE:119164.1] Changing Database Character set - Valid Superset definitions [NOTE:118242.1] ALERT: Changing the Database or National Character Set Can Corrupt LOB Values <Note.158577.1> NLS_LANG Explained (How Does Client-Server Character Conversion Work?) [NOTE:140014.1] ALERT: Oracle8/8i to Oracle9i using New "AL16UTF16" [NOTE:159657.1] Complete Upgrade Checklist for Manual Upgrades from 8.X / 9.0.1 to Oracle9i (incl. 9.2) [NOTE:124721.1] Migrating an Applications Installation to a New Character Set Oracle8i National Language Support Guide Oracle8i Release 3 (8.1.7) Readme - Section 18.12 "Restricted ALTER DATABASE CHARACTER SET Command Support (CLOB and NCLOB)" Oracle8i Documentation Addendum, Release 3 (8.1.7) - Chapter 3 "New Character Set Scanner Utility" Oracle8i Application Developer's Guide - Large Objects (LOBs), Release 2 - Chapter 2 "Basic Components" Oracle8 Application Developer's Guide, Release 8.0 - Chapter 6 "Large Objects (LOBs)", Section "Introduction to LOBs" Oracle9i Globalization Guide, Release 1 (9.0.1) Oracle9i Database Globalization Guide, Release 2 (9.2) For further NLS / Globalization information you may start here: [NOTE:150091.1] Globalization Technology (NLS) Library index .
 Copyright (c) 1995,2000 Oracle Corporation. All Rights Reserved. Legal Notices and Terms of Use.
Joel P�rez

How to insert a CLOB in Oracle8.0 with JDBC

Hi,
I'm having trouble to insert a CLOB into a table with java. I'm using JDK1.1.8 and Oracle8.0
I've to insert more 4000 char String into that field. What can I do? Any example is very appreciate.

This is a problem with the driver. It is a known bug/issue.
You have to use the dbms_lob.write procedure and append data to the clob inside a loop.
i.e. do something like (pseudo-code)
while(file.not_end)
char[] buffer= file.read(start_pos,bytes_read);
dmbs_lob.write(buffer);
start_pos = start_pos+ bytes_read;
null

$200 reward to solve problem with JDBC and CLOB.getCharacterOutputStream

I'm trying to update CLOB with the getCharacterOutputStream as suggested in the example code. It works with US7ASCII DB instance but not instances in UTF8.
I've been browsing through all the Oracle doc's and found some rather confusing statements:
In the page at http://oradoc.photo.net/ora816/java.816/a81354/oralob2.htm#1043220
it says: [When writing to or reading from a CLOB, the JDBC drivers perform all character set conversions for you.]
also: [The oracle.sql.CLOB class supports all the character sets that the Oracle data server supports for CLOB types.]
So far so good.
In the page at http://oradoc.photo.net/ora816/java.816/a81354/oraint3.htm#1012518
it says [The oracle.sql package supports these datatypes in several ways: CLOBs point to large fixed-width character data items (that is, characters that require a fixed number of bytes per character) and are supported by the oracle.sql.CLOB class.]
Ooh no! Is this for real? UTF8 is variable width and does this mean it is not supported?
Any way to get around this?
In the page at http://oradoc.photo.net/ora816/java.816/a81358/03_pub2.htm#36009
says [6.The mappings to oracle.sql classes are optimal because they preserve data formats and require no character-set conversions (apart from the usual network conversions). Those classes are especially useful in applications that "shovel" data between SQL and Java.]
"No character set conversion"? Very confusing!
I've been hammering on this CLOB/JDBC/UTF8 problem for more than a week now and I really appreciate some solutions, workarounds, or whatever help I can get. I'm running java stored procedure in 8.1.6 on Linux RH6.2.
For your trouble, I'd pay $200 for the first guy who come up with a verifiable solution.

This is just findings based upon your comments:
Please refer to document Oracle8i National Language Support Guide
Release 2 (8.1.6) from Oracle Documentation Library, Release 8.1.7
Chapter 6 Java,
There its clearly mention that:
"Oracle JDBC drivers provide globalization support by allowing users to retrieve data from or insert data into a database in any character set that Oracle supports. Because Java strings are UCS2 encoded (16-bit Unicode) for JDBC programs, the target character set on the client is always UCS2. Character set conversion is required to convert data from the database character set (Db Charset) to UCS2. This applies to CHAR, LONG, CLOB, and VARCHAR2 data types; RAW data is not converted. "
Also..please refer this...
"oracle.sql.CLOB's method getCharacterStream() returns the contents of a CLOB as a Unicode stream."
"The techniques that Oracle's drivers use to perform character set conversion for Java applications depend on the character set the database uses. The simplest case is where the database uses a US7ASCII or WE8ISO8859P1 character set. In this case, the driver converts the data directly from the database character set to UCS2,which is used in Java applications. "
"If you are working with databases that employ a non-US7ASCII or non-WE8ISO8859P1 character set (for example, Japanese or Korean), then the driver converts the data, first to UTF8, then to UCS2. "
In my case the characte-set of the database is WE8ISO8859P1 and for security reason i can't change the character set but my feeling is that if you are updating the CLob from the java client you are forming a reference of a clob in the client which is UCS2 at the Java side. Now when you are populating the clob through java.io.Writer and call the procedure to pass the reference of the clob to the procedure then I believe the JDBC will convert the UCS2 datatype of Clob to UTF8 in the database.
You can try out the code snippet:
package ServletGDC;
import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
import oracle.sql.*;
import java.sql.*;
import oracle.jdbc.driver.*;
import ClassesGDC.*;
public class testUpload extends HttpServlet {
private String m_strMessage="";//It stores the message to be uploaded along with the Document
Connection conn=null;
public void doPost(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
String strContent="";
//res.setContentType("application/msword");
res.setContentType("text/html");
PrintWriter out = res.getWriter();
try {
CallableStatement cmt=null;
OutputStream output=null;
ByteArrayOutputStream byteoutput=null;
String strDocString="";
oracle.sql.CLOB tempClob = null;
String strPassedFileName=""; // the file name passed in the request object
String strStdFilename="";//the file name to be given to the best practice
String strSaveDirectory=""; //the directory in which the bp is to be saved
String strParamName="";//name of parameters
String strParamValue="";//value of parameters
int intTempVariable=0; // temporaty variable
long lngSizeOfFileUploaded=0;//stores the size of the file which had been uploaded in the file system
File filePathOfFileUploaded=null;//stores the path of the file uploaded to the file system
String strQuery="";
//ST------------checks if the user has logged in or not-----------------------
HttpSession session=req.getSession(true);
if(req.getContentLength()>20*1024*1024)
throw new skip("The size of the posted content is more than 10 MB . If you have a best practice whose size is more than 1 MB please mail it to Us.");
byteoutput = new ByteArrayOutputStream();
MultipartParser mp = new MultipartParser(req, 20*1024*1024); // 10MB is the limit of the file to be uploaded
Part part;//Its an abstact part which helps in retrieving information about the file and the parameters
while ((part = mp.readNextPart()) != null) {//Reads the next part
strParamName = part.getName();
// the following if is executed if the part is for a parameter rather than a file
if (part.isParam()) {
}else if (part.isFile()) {
// it's a file part
m_strMessage="inside file part";
FilePart filePart = (FilePart) part;
strPassedFileName = filePart.getFileName();
strContent= filePart.getContentType();
out.println(" strPassedFileName is "+strPassedFileName+"");
if(strPassedFileName != null || !(strPassedFileName.trim().equals("")) ) {
// the part actually contained a file
out.println(" before forming long");
//lngSizeOfFileUploaded = filePart.writeTo(filePathOfFileUploaded); //the statement upload the bestpractice in the
lngSizeOfFileUploaded = filePart.writeTo(byteoutput); //specified file path filePathOfFileUploaded.
out.println(" after file is written into the outputstream");
else {
throw new skip("The file name is null or it is empty space. Files in such Format are not accepted");
}//end of else if
}//end of while loop
if( lngSizeOfFileUploaded==0) {// the size of the file uploaded is zero then the file supplied was not proper and hence exception is to be thrown
//if(filePathOfFileUploaded.exists())
// filePathOfFileUploaded.delete();
throw new skip("The File could not be uploaded,Possible reasons may be that the file is sent null or the file is corrupted");
//END---------------the file is uploaded in the proper directory--------------------
//res.setContentType(strContent);
out.println(" long value is : "+lngSizeOfFileUploaded+" and content is "+strContent+"");
String strbyte= byteoutput.toString();
byteoutput.flush();
Class.forName("oracle.jdbc.driver.OracleDriver");
// Establish network connection to database
conn = DriverManager.getConnection("jdbc:oracle:thin:@pc-p32670:1521:GDCDBI","gdc_user","myuser");
//if(conn!=null)
out.println(" Connection formed"+conn);
//els
//out.println(" long value is : "+strbyte+"");
try{
tempClob = oracle.sql.CLOB.createTemporary(conn,true, oracle.sql.CLOB.DURATION_SESSION);
out.println(" tempClob : "+tempClob);
tempClob.open( oracle.sql.CLOB.MODE_READWRITE);
java.io.Writer tempClobWriter = tempClob.getCharacterOutputStream();
// writing the string formed from the multipart file to the clob
tempClobWriter.write(strbyte);
if(tempClob!=null){}
out.println(" CLOB value is : "+tempClob+"");
strQuery="{call INSERT_CLOB(?,?)}";
cmt=conn.prepareCall(strQuery);
cmt.setString(1,strPassedFileName);
cmt.setClob(2,tempClob);
cmt.registerOutParameter(2,java.sql.Types.CLOB);
cmt.execute();
tempClobWriter.flush();
tempClobWriter.close();
tempClob.freeTemporary();
//res.setContentType(strContent);
//strDocString.toString();
out.println(" bob is "+strbyte+"");
tempClob.close();
}catch(Exception e){
tempClob.close();
out.println(" Error is :"+e.getMessage()+"");
//e.printStackTrace(out);
cmt.close();
//out.println(" <h2>SUCCESS</h2>");
//res.sendRedirect("../test/showfile.jsp?contentype="+strContent.trim()+"");
}catch(Exception e){
java.util.Date d = new java.util.Date();
String s =d.toString();
out.println(" Error is :"+e.getMessage()+"");
//e.printStackTrace(out);
}finally{
try{
if(conn!=null)
conn.close();
}catch(Exception e){
out.println(" Error is :"+e.getMessage()+"");
}// end of finally
} //end of doPost
} //end of class
in the Procedure you will be inserting/updating the clob in a table with the reference clob in the out parameter of the procedure
Thanks.

How to retrieve data from a field of CLOB datatype?

How can I retrieve data from a field of CLOB datatype in Oracle
8 being called from an ASP or VB application? The recordset
object in ASP or VB doesn't support the CLOB datatype.
Thank you in advance for your help.

How can I retrieve data from a field of CLOB datatype in Oracle
8 being called from an ASP or VB application? The recordset
object in ASP or VB doesn't support the CLOB datatype.
Thank you in advance for your help. Hello.. were you able to solve your problem? I'm faced with pretty much the same task.. I have a VBA application that needs to pull various pieces of data(CLOBs, BLOBs, etc..) from an Oracle8i db.

Retrieving data from a relational table and CLOB as a whole XML file

I created the table lob_example and I have managed to insert XML document into it using XML SQL Utility. In this document I put contents of <DESCRIPTION> tag into CDATA section.
LOB_EXAMPLE
Name Null? Type
ID NOT NULL NUMBER
DESCRIPTION CLOB
NAME VARCHAR2(40)
But I could not retrieve this data properly. I can think of only one solution - to parse and build the whole XMLDocument. I found the suggestion of another solution to use Oracle8i views to do that in http://technet.oracle.com/tech/xml/infoocs/otnwp/about_oracle_xml_products.htm, but this text is not clear enough for me.
I would like to quote the fragment from document mentioned above, which is ambiguous for me:
"Combining XML Documents and Data Using Views
Finally, if you have a combination of structured and unstructured XML data, but still want to view and operate on it as a whole, you can use Oracle8i views. Views enable you to construct an object on the "fly" by combining XML data stored in a variety of ways. So, you can store structured data (such as employee data, customer data, and so on) in one location within object -relational tables, and store related unstructured data (such as descriptions and comments) within a CLOB. When you need to retrieve the data as a whole, you simply construct the structure from the various pieces of data with the use of type constructors in the view's select statement. The XML SQL Utility then enables retrieving the constructed data from the view as a single XML document."
The main question is - how to use type constructors in the view's select statement?

Hello
Sorry for asking the same question again, but any responses would be greatly appreciated.
How to use type constructors in the view's select statement?
I could not find any answers for this question on Technet. Maybe the other approaches are more efficient to combine the part of data from CLOB with data from other column types?
Thank you

PL/SQL + Parser: CLOB/Encoding

I'm traying to create my XML document in PL/SQL but the method
setCharset('ISO-8859-1')
does not work and is ignored. it works only with
setCharset('UTF8').
Does anybody know why??? Is this a bug??
There is also another issue:
We're using the Oracle XML Parser for PLSQL 1.0.2.0.0 on a Windows NT platform.
We're using the very latest available version of Oracle8i and Java.
When using the xmldom.WriteToCLOB procedure most of the non-US ASCII characters gets
converted to an inverterted question-mark.
When we use xmldom.WriteToFile the file contents are correct
(i.e. shows all ISO-8859-1 characters correctly on the NT platform).
Is it a bug in WriteToCLOB? If yes, is there any chance that it will be fixed, shortly??

1/ we have filed a bug for your first question.
2/ for you second question, we have notice our limitation on current pl/sql API.
This mostly because of CLOB limitation:
As we known, the character repertoire of CLOB is limited by the database character set. This limitation may cause data loss if the database character set wasn't UTF8.
Please just ignore this API. In future release, we will accept new datatype "xmlobject". This will solve this problem.
Thanks for point out this problem.

MS sql server text column to 8.0.5 CLOB

my env: MS SQL SERVER (6.5 and 7.0) Oracle 8..0.5/8i
I have a 'products' table a sub-definition of which is:
MS sql server definition
create table products(
productid int IDENTITY(1,1) not null
,name varchar (255)
,description TEXT)
Oracle8 definition
create table products(
productid number(10) not null
,name varchar2(255)
,description CLOB)
My question is:
In sqlserver I have a query:
SELECT productid, name FROM products
WHERE products.description LIKE '%some text%';
The above query works in sqlserver but the equivalent query in
Oracle does not work i.e. I get the following error
ORA-00932: inconsistent datatypes
The error description does not fully explain my situation.
I want to confirm that I cannot have as part of my 'WHERE CLAUSE'
a reference to a 'CLOB' column i.e.
'WHERE clob.column LIKE '%SOME TEXT%'. If I cannot do this, how
else can I do it (without using Oracle's Context/Intermedia
option) or am I doing something incorrectly.
Your valuable suggestions/comments are most appreciated.
Regards
Harry Gill
null

It may also be useful for you to take a look at the Intermedia
documentation.
And finally, Oracle Development say they are currently looking at
implementing LIKE for Clobs in future releases.
Oracle Migration Workbench Team wrote:
: Hi Harry,
: Here is a reply I got. dbms_lob is a pl/SQL package. You can
find
: more information on this in the application developers guide
and
: pl/sql developers guide.
: use the dbms_lob.instr() function to get like functionality in
: clobs.
: It is not perfect but meets your requirements.
: e.g.
: SELECT productid, name
: FROM products
: WHERE dbms_lob.instr(products.description,'some text',1,1) > 0;
: John
: Oracle Migration Workbench Team wrote:
: : Hi Harry,
: : I have fowarded your query to some more people within Oracle.
: : I can suggest some different approaches that use PL/SQL or
Java
: : but I would like to see what other developers recommend.
: : Do you have access to the Oracle8i Application Developers
: guide.
: : There should be some code samples there that can help.
: : John
: : Harry Gill (guest) wrote:
: : : my env: MS SQL SERVER (6.5 and 7.0) Oracle 8..0.5/8i
: : : I have a 'products' table a sub-definition of which is:
: : : MS sql server definition
: : : create table products(
: : : productid int IDENTITY(1,1) not null
: : : ,name varchar (255)
: : : ,description TEXT)
: : : Oracle8 definition
: : : create table products(
: : : productid number(10) not null
: : : ,name varchar2(255)
: : : ,description CLOB)
: : : My question is:
: : : In sqlserver I have a query:
: : : SELECT productid, name FROM products
: : : WHERE products.description LIKE '%some text%';
: : : The above query works in sqlserver but the equivalent query
: in
: : : Oracle does not work i.e. I get the following error
: : : ORA-00932: inconsistent datatypes
: : : The error description does not fully explain my situation.
: : : I want to confirm that I cannot have as part of my 'WHERE
: : CLAUSE'
: : : a reference to a 'CLOB' column i.e.
: : : 'WHERE clob.column LIKE '%SOME TEXT%'. If I cannot do this,
: how
: : : else can I do it (without using Oracle's Context/Intermedia
: : : option) or am I doing something incorrectly.
: : : Your valuable suggestions/comments are most appreciated.
: : : Regards
: : : Harry Gill
: : Oracle Technology Network
: : http://technet.oracle.com
: Oracle Technology Network
: http://technet.oracle.com
Oracle Technology Network
http://technet.oracle.com
null

Yest we can store BLOB,CLOB

Hi,
it is possible to strore the BLOB , CLOB and BFILES IN THE ORACLE8 and above DATABASE.
For this you can take the help of the DBMS_LOB package.
regards,
khaleel

How do you propose to do that? You are limited to 255 bytes per cell in Excel. If you come up with a scheme to lay down blocks of data and some way to uniquely ID them, then yes, you can; but you have to overcome that 255 byte boundary per cell before you can do much.
A CLOB can be stored as a string, but once again... there is that max character boundary to overcome in Excel.

Using CLOB in 8.1.7

Hi,
Well, everything here seems simple with the use of CLOB. But unfortunately, it springs up a surprise,to me atleast, when compiled.
l_clob clob :=
'<?xml version = "1.0"?>
 <ROWSET>
 <ROW num="1">
 <EMPNO>7369</EMPNO>
 <ENAME>SEANDILLON</ENAME>
 <JOB>DBDUDE</JOB>
 <MGR>7902</MGR>
 <HIREDATE>12/17/1980 0:0:0</HIREDATE>
 <SAL>800</SAL>
 <DEPTNO>20</DEPTNO>
 </ROW>
 <ROW num="2">
 <EMPNO>7499</EMPNO>
 <ENAME>TOMKYTE</ENAME>
 <JOB>DBDUDE</JOB>
 <MGR>7698</MGR>
 <HIREDATE>2/20/1981 0:0:0</HIREDATE>
 <SAL>1600</SAL>
 <COMM>300</COMM>
 <DEPTNO>30</DEPTNO>
 </ROW>
 <ROW num="3">
 <EMPNO>7521</EMPNO>
 <ENAME>MICKEYMOUS</ENAME>
 <JOB>RAT</JOB>
 <MGR>7698</MGR>
 <HIREDATE>2/22/1981 0:0:0</HIREDATE>
 <SAL>1250</SAL>
 <COMM>500</COMM>
 <DEPTNO>30</DEPTNO>
 </ROW>
 </ROWSET>';
It throws the following error
PLS-00382: expression is of wrong type. What is astonishing is even if I initialize l_clob with a simple value like 'Hello World',the error persists.Can anyone please help me.

The problem is that works into a 9.2 database :
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production
SQL> declare
2 l_clob clob :=
3 '<?xml version = "1.0"?>
4 <ROWSET>
5 <ROW num="1">
6 <EMPNO>7369</EMPNO>
7 <ENAME>SEANDILLON</ENAME>
8 <JOB>DBDUDE</JOB>
9 <MGR>7902</MGR>
10 <HIREDATE>12/17/1980 0:0:0</HIREDATE>
11 <SAL>800</SAL>
12 <DEPTNO>20</DEPTNO>
13 </ROW>
14 <ROW num="2">
15 <EMPNO>7499</EMPNO>
16 <ENAME>TOMKYTE</ENAME>
17 <JOB>DBDUDE</JOB>
18 <MGR>7698</MGR>
19 <HIREDATE>2/20/1981 0:0:0</HIREDATE>
20 <SAL>1600</SAL>
21 <COMM>300</COMM>
22 <DEPTNO>30</DEPTNO>
23 </ROW>
24 <ROW num="3">
25 <EMPNO>7521</EMPNO>
26 <ENAME>MICKEYMOUS</ENAME>
27 <JOB>RAT</JOB>
28 <MGR>7698</MGR>
29 <HIREDATE>2/22/1981 0:0:0</HIREDATE>
30 <SAL>1250</SAL>
31 <COMM>500</COMM>
32 <DEPTNO>30</DEPTNO>
33 </ROW>
34 </ROWSET>';
35 begin
36 null;
37 end;
38 /
PL/SQL procedure successfully completed.
SQL> And not work onto my old 8i db like for the OP.
Connected to:
Oracle8i Enterprise Edition Release 8.1.7.4.0 - 64bit Production
With the Partitioning option
JServer Release 8.1.7.4.0 - 64bit Production
SQL> declare
2 l_clob clob :=
3 '<?xml version = "1.0"?>
4 <ROWSET>
5 <ROW num="1">
6 <EMPNO>7369</EMPNO>
7 <ENAME>SEANDILLON</ENAME>
8 <JOB>DBDUDE</JOB>
9 <MGR>7902</MGR>
10 <HIREDATE>12/17/1980 0:0:0</HIREDATE>
11 <SAL>800</SAL>
12 <DEPTNO>20</DEPTNO>
13 </ROW>
14 <ROW num="2">
15 <EMPNO>7499</EMPNO>
16 <ENAME>TOMKYTE</ENAME>
17 <JOB>DBDUDE</JOB>
18 <MGR>7698</MGR>
19 <HIREDATE>2/20/1981 0:0:0</HIREDATE>
20 <SAL>1600</SAL>
21 <COMM>300</COMM>
22 <DEPTNO>30</DEPTNO>
23 </ROW>
24 <ROW num="3">
25 <EMPNO>7521</EMPNO>
26 <ENAME>MICKEYMOUS</ENAME>
27 <JOB>RAT</JOB>
28 <MGR>7698</MGR>
29 <HIREDATE>2/22/1981 0:0:0</HIREDATE>
30 <SAL>1250</SAL>
31 <COMM>500</COMM>
32 <DEPTNO>30</DEPTNO>
33 </ROW>
34 </ROWSET>';
35 begin
36 null;
37 end;
38 /
'<?xml version = "1.0"?>
ERROR at line 3:
ORA-06550: line 3, column 1:
PLS-00382: expression is of wrong type
ORA-06550: line 2, column 8:
PL/SQL: Item ignoredNicolas.

How to load XML files into ORACLE8i database?

SAP data is being extracted into XML format (via IDOC) files which are being transferred to an ORACLE8i box. There will be a large amount of data transferred on a daily basis which will include updates and inserts. From all the information that I have read on this subject there are 2 options available :
1. XML-SQL Utility - which converts XML into INSERT, UPDATE or DELETE SQL. There does not appear to be that much functionality available by this method for decodes, transformations on the input data.
2. SQL*Loader - There was a statement in 1 piece of documentation stating that SQL*Loader could be used for loading XML format data files. I cannot however find any further information on how this is achieved or how it works.
If anyone has any experience in loading XML format data files using either of the above methods (preferably SQL*Loader as it has more functionality) then could you please provide me with examples or guidance on this matter? Any help would be greatly appreciated as I am not familiar with XML format data files. I am from an Oracle 7.3 background but do not have much experience with Oracle 8 onwards.
Disclaimer.
Any views expressed in the above paragraphs are my own and not that of Hewlett Packard Ltd.

We are loading XML into our database using CLOB datatypes. We don't use the XSU for inserts as it is too slow. We parse the incoming XML document into a PL/SQL record type and then build a generic insert. This might not work well if you have many tags to parse into columns. We also store the entire XML CLOB into a column without parsing the individual tags into separate columns. We then use Intermedia Text for fast, index-based searching within the XML column.
Check out The Oracle XML Portal website for code examples on how to do this:
www.webspedite.com/oracle

Cannot find Symbol :class CLOB

Hi,
I am using JDK1.5.0_06 and Oracle8.1.7.
When i compile java program I am getting the following error
cannot find symbol
symbol : class CLOB
I have added classes12.zip into classpath.
Can anybody tell me why this errpr comes? Is there any other files instead of classes12.zip to be added (since its JDK1.5 version? )
Thanks in advance
neema

you have mentioned about the class "studentList" but that class is not to be found in the code you have pasted. its instead "ListTest". And the "menu" function seems to b a part of "ListTest" class. Can you provide the structure of the classes "studentList" and "Student" so that the problem can be more clearly understood?
also you are using the variable "Stdin" in the line int choice = Stdin.readInteger(); where as you have not declared this variable.
in the "switch" statement you are calling two different functions for the same case "3" where as it should be "case 3" and "case 4" respectively.
in the "main" you are calling the "menu" function without any parameter while you actually want to pass argument of type "studentList".

CLOBS - Access2000 to Oracle8i

Similar Messages

Maybe you are looking for