Using DBMS_DATAPUMP with LONG data type

Question

I've got a procedure below that calls the DBMS_DATAPUMP procedure using a REMOTE_LINK to move a schema from one database to another. However, a couple of the tables within that schema have columns with the LONG data type. And when I run it I get an error saying that you cannot move data with the LONG data type using a REMOTE LINK. So no data in those particular tables gets moved over.
Has anyone else had this issue? If so, do you have a work around? I tried adding a CLOB column to my table and setting the new CLOB to equal the LONG, but I couldn't get that to work either...even when I tried using a TO_LOB. If I could get that to, then I could just drop the LONG, move the schema, then recreate the LONG column on the opposite side.
Here's my procedure....
DECLARE
     /* EXPORT/IMPORT VARIABLES */
     v_dp_job_handle                    NUMBER ;          -- Data Pump job handle
     v_count                              NUMBER ;          -- Loop index
     v_percent_done                    NUMBER ;          -- Percentage of job complete
     v_job_state                         VARCHAR2(30) ;     -- To keep track of job state
     v_message                         KU$_LOGENTRY ;     -- For WIP and error messages
     v_job_status                    KU$_JOBSTATUS ;     -- The job status from get_status
     v_status                         KU$_STATUS ;     -- The status object returned by get_status
     v_logfile                         NUMBER ;
     v_date                              VARCHAR2(13) ;
     v_source_server_name          VARCHAR2(50) ;
     v_destination_server_name     VARCHAR2(50) ;
BEGIN
     v_project := 'TEST' ;
     v_date := TO_CHAR(SYSDATE, 'MMDDYYYY_HHMI') ;
     v_source_server_name := 'TEST_DB' ;
     v_dp_job_handle := DBMS_DATAPUMP.OPEN(
          OPERATION     => 'IMPORT',
          JOB_MODE     => 'SCHEMA',
          REMOTE_LINK => v_source_server_name,
          JOB_NAME     => v_project||'_EXP_'||v_date,
          VERSION          => 'LATEST') ;
     v_logfile := DBMS_DATAPUMP.KU$_FILE_TYPE_LOG_FILE ;
     DBMS_DATAPUMP.ADD_FILE(
          HANDLE          => v_dp_job_handle,
          FILENAME     => v_project||'_EXP_'||v_date||'.LOG',
          DIRECTORY     => 'DATAPUMP',
          FILETYPE     => v_logfile) ;
     DBMS_DATAPUMP.METADATA_FILTER(
          HANDLE          => v_dp_job_handle,
          NAME          => 'SCHEMA_EXPR',
          VALUE          => '= '''||v_project||''' ') ;
     DBMS_DATAPUMP.START_JOB(v_dp_job_handle) ;
     v_percent_done := 0 ;
     v_job_state := 'UNDEFINED' ;
     WHILE (v_job_state != 'COMPLETED') AND (v_job_state != 'STOPPED')
     LOOP
          DBMS_DATAPUMP.GET_STATUS(
               v_dp_job_handle,
               DBMS_DATAPUMP.KU$_STATUS_JOB_ERROR + DBMS_DATAPUMP.KU$_STATUS_JOB_STATUS + DBMS_DATAPUMP.KU$_STATUS_WIP,
               -1,
               v_job_state,
               v_status) ;
               v_job_status := v_status.JOB_STATUS ;
          IF v_job_status.PERCENT_DONE != v_percent_done THEN
               DBMS_OUTPUT.PUT_LINE('*** Job percent done = '||TO_CHAR(v_job_status.PERCENT_DONE)) ;
               v_percent_done := v_job_status.PERCENT_DONE ;
          END IF ;
          IF BITAND(v_status.MASK, DBMS_DATAPUMP.KU$_STATUS_WIP) != 0 THEN
               v_message := v_status.WIP ;
          ELSIF BITAND(v_status.mask, DBMS_DATAPUMP.KU$_STATUS_JOB_ERROR) != 0 THEN
               v_message := v_status.ERROR ;
          ELSE
               v_message := NULL ;
          END IF ;
          IF v_message IS NOT NULL THEN
               v_count := v_message.FIRST ;
               WHILE v_count IS NOT NULL
               LOOP
                    DBMS_OUTPUT.PUT_LINE(v_message(v_count).LOGTEXT) ;
                    v_count := v_message.NEXT(v_count) ;
               END LOOP ;
          END IF ;
     END LOOP ;
     DBMS_OUTPUT.PUT_LINE('Job has completed') ;
     DBMS_OUTPUT.PUT_LINE('Final job state = '||v_job_state) ;
     DBMS_DATAPUMP.DETACH(v_dp_job_handle) ;
END ;

Answer 1

But the application we have that uses the database cannot be changed to read from a CLOBWhy can't you change the application?
Well, anyway you should point out to your superiors that Oracle documented years ago to not use LONGS anymore...
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/datatype.htm#sthref3806
It clearly states:
LONG Datatype
Note:
Do not create tables with LONG columns. Use LOB columns (CLOB, NCLOB) instead. LONG columns are supported only for backward compatibility.
Oracle also recommends that you convert existing LONG columns to LOB columns. LOB columns are subject to far fewer restrictions than LONG columns. Further, LOB functionality is enhanced in every release, whereas LONG functionality has been static for several releases.
How do I go from CLOB to LONG?I'm sorry, cannot help you on that one, I don't think you can do that at all (Oracle wants us to stop using LONGS, so, it's a one-way conversion...):
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1037232794454#15512131314505
So: NO built_in, you'll need to write a program if the clob is ALWAYS LESS THAN 32k in size, you can use plsql..but is that the case in your case? Only you know that.
I believe that question is still unanswered on this forum, but you might try searchin for answers on this forum, and
the 'Database-General' forum: General Database Discussions
Perhaps you can google a Q&D workaround...
( And consider convincing your collegues to just convert your LONGS to LOBS)
Edited by: hoek on Apr 8, 2009 5:43 PM