query on the column data type CLOB display part of instruction. Why?

Similar Questions

• XMLTable: definition of the columns data type of table

  Hello world
  
  I am using ORACLE 11 g and you want to shred XML into a table called test used. I was hoping I'd be able to get the types of data to the employees table existing instead of specify them in the clause of columns. Is this possible?
  
  Here is an example of what I'm trying to do. But I get an error: PL/SQL: ORA-00907: lack the right parenthesis on the line starting with columns.
  

      insert into EMPLOYEES
       select *
         from xmltable(
         '/employees/employee'
          passing EMP_XML
  
          columns FIRST_NAME EMPLOYEES.FIRST_NAME%TYPE path 'first_name',
                  LAST_NAME  EMPLOYEES.LAST_NAME%TYPE  path 'last_name',
                  GENDER     EMPLOYEES.GENDER%TYPE     path 'gender',
                  AGE        EMPLOYEES.AGE%TYPE        path 'age'
          );

  Error details

          columns FIRST_NAME EMPLOYEES.FIRST_NAME%TYPE path 'first_name',
                              *          
  
  ERROR at line 16:
  ORA-06550: line 16, column 42:
  PL/SQL: ORA-00907: missing right parenthesis
  ORA-06550: line 11, column 5:
  PL/SQL: SQL Statement ignored

  Thank you.

  Specification of column names is required, but you can omit the declaration of data types.

  See: the function XMLTABLE SQL/XML in Oracle XML DB

  XMLTable is used with storage XML based on a schema of XMLType data type is optional. If absent, the data type is inferred from the XML schema. If Oracle > XML DB is unable to determine the right type of a node, a default type VARCHAR2 (4000) is used.

  It is an Oracle extension; in the SQL/XML standard, the data type is always required.

  Note:
  The alleged data type might change as a result of the application of a patch or upgrade of Oracle XML DB. In particular, a new set of release or patch might be able to > determine the data type when the previous version was unable to do so (and therefore not reimbursed to VARCHAR2 (4000)). To protect against such an eventuality, specify an explicit data type with the data type.

• convert the money data type in a decimal format 2.

  What is the best way to convert the money data type in a decimal 2 format in ms sql 2005 for use in my applications.

  This?

  CAST (tr.depositReceivedAmount AS decimal (10, 2))

  I respectfully disagree with the idea that you must change the query column a type of 'money' data to something else.

  In most database servers, "«argent» Silver" is a data type that is designed to provide a very homogeneous behaviour with regard to the arithmetic accuracy.  In Microsoft Access, the representation is a the whole scale.  MS SQL Server, it is obviously similar.  Ditto Oracle and others.

  You like that the money data type in the database for this clarification, because "hell has no fury like an accountant looking for a bad penny."   The column of database storage formats are designed to satisfy the accountants, and it's a good thing.

  Meanwhile, you also want to take care as to exactly how you are dealing with values.  There are several points where the district could take place.  You don't have available the strongest possible manipulation of the floating of the data types in ColdFusion.  You also are somewhat at the mercy of any interface software can be between you and that SQL server, you can use.  "It is correct to all about values , but not several times."

  I suggest to round the value just before the display and user input must be two decimals.

  Then, you may need to do some things at the end of SQL server.  For example, when you update a value in the table, you may need to use logical server to explicitly truncate the value to two decimal places, as well as an update of "$ 34,56" explicitly updates the column "$34,5600.."  (This kind of thing should happen in the context of SQL Server).  You know that the user entry has exactly two significant digits, but maybe (maybe not...)! SQL server may not know this.  You want to ensure that the stored server internally represents exactly two digits, when the origin of a user input value.

  Do not err on the side of "convenience" or "which seems." good on the screen  (If you do, get ready get telephone communications of the accountants, always at inappropriate times of the night.)

• Impact on performance when you use the LONG data type

  Hi all
  
  
  Only I have a doubt about the use of LONG data type
  
  I use the data type LONG for some columns in a table and I created indexes on the columns separately, but these column values can be easily fit into the varchar data type.
  
  (Just to see the performance on this issue)
  
  Suppose that a common select query with WHERE condition on any of the column which has LONG data type will affect the performance of the query?
  
  Please explain.
  
  Thank you

  (1) the LONG (and LONG RAW) data types have been depricated for quite a while. Oracle has been strongly recommends that you move to 8.1.5 CLOB and BLOB data types. Why you use the LONG data type? You're still on Oracle 7?

  (2) have you tried to write a query that has a WHERE condition that refers to a LONG column? In general, you can not because it does not support the type of data LONG. For example

  SQL> ed
  Wrote file afiedt.buf
  
    1  create table a (
    2    col1 varchar2(30),
    3    col2 long
    4* )
  SQL> /
  
  Table created.
  
  SQL> select * from a where col2='abc';
  select * from a where col2='abc'
                        *
  ERROR at line 1:
  ORA-00997: illegal use of LONG datatype
  

  LONG data types are a royal pain to work with. They also have implications on the performance of wicked on the client.

  Justin

• As an operator with the long data type

  Oracle 10g.

  Hi gurus

  I want to apply as an operator on the long data type, but I get the error message, can you please help me why is that I use as an operator with the long data type. I did some research and but unable to find a solution, see query for more details below...

  Query

  SELECT trigger_body FROM user_triggers

  WHERE trigger_body LIKE '% UPDA % CASE % ';

  Error

  ORA-00932: inconsistent data types: expected NUMBER got LONG

  00932 00000 - ' incompatible data types: wait %s %s got. "

  * Cause:

  * Action:

  Error on line: column 2: 7

  Concerning

  Muzz

  Adrian Billington wrote to the top of your options.

  working with long columns

• Syntex to create the table with the long data type

  I'm looking to create a table based on another table that having the column long data type. Throw the error ORA-00997: illegal use of the LONG data type

  
  I tired it

  create table abc_long (ag bgd long number);

  create table abc_long_dummy as ( ) Select *of abc_long); - ORA-00997 error: illegal use of the LONG data type

  How to get there?

  I'm looking to create a table based on another table that having the column long data type.

  You really don't want to do that.

  LONG data type has been deprecated for some time now, use CLOB.

  The TO_LOB() function will do the conversion on the fly:

  create table abc_long_dummy
  as
  select ag
       , to_lob(bgd) as bgd
  from abc_long ;
  

• Confusion of length of column data type

  Hi all

  To learn about my column data type and length, I have run the following query. However, when I confirm it with the table_name desc command, I see that the lengths of data do not correspond. You have an idea?

  > > select column_name | » '|| DATA_TYPE | » ('|| ( data_length|') ' col_info all_tab_columns where table_name = 'CUSTTABLE' and column_name = 'ACCOUNTNUM;

  > > ACCOUNTNUM NVARCHAR2 (24)

  > > desc CUSTTABLE.

  > > ACCOUNTNUM 1 N NVARCHAR2 (12)

  Concerning

  Charlie

  NightWing wrote:

  By the way I couln t understand what were you thinking when you explain to no.

  I missed you NVARCHAR2 column and thought it was VARCHAR2. When you declare the semantics of VARCHAR2 column length is specified explicitly or implicitly. Explicitly suffixing length with BYTE or CHAR and implicitly when you specify the length of the right itself. Then length is based on the value NLS_LENGTH_SEMANTICS session. So let's assume you generate table create statement (and it seems that you is, based on column_name |) » '|| DATA_TYPE | » ('|| ( data_length|') ' ). Then it does not matter if use use data_length or char_col_decl_length. It will be regadless semantics implied length of what you use. Therefore, when you run create table instructions column length will be interpreted as bytes if current NLS_LENGTH_SEMANTICS byte value. But same length is interpreted as the characters if current NLS_LENGTH_SEMANTICS a char value. As you can see, in order to generate create table statement we use explicit semantic length column, otherwise create table statement can produce lengths of different column in the source table.

  SY.

• How to cut the column data

  Gurus in the morning
  
  I have two tables with the data in the corresponding column, BUT I need to cut the columns in a table
  the data is displayed as follows in table xpq_log

  LOG_DATE                     LOG_PTR     LOG_HDR
  01/06/2011 00:00:00     0609pro     0609IN002C_06
  04/06/2011 00:00:00     0609pro     0609IN002C_06
  05/06/2011 00:00:00     0609pro     0609IN002C_06
  06/06/2011 00:00:00     0609pro     0609IN002C_06
  07/06/2011 00:00:00     0609pro     0609IN002C_06
  09/06/2011 00:00:00     0609pro     0609IN002C_06
  10/06/2011 00:00:00     0609pro     0609IN002C_06
  12/06/2011 00:00:00     0609pro     0609IN002C_06
  01/06/2012 00:00:00     0609pro     0609IN002C_06
  02/06/2012 00:00:00     0609pro     0609IN002C_06
  03/06/2012 00:00:00     0609pro     0609IN002C_06
  06/06/2012 00:00:00     0609pro     0609IN002C_06
  07/06/2012 00:00:00     0609pro     0609IN002C_06
  08/06/2012 00:00:00     0609pro     0609IN002C_06
  09/06/2012 00:00:00     0609pro     0609IN002C_06

  In the table of printpdf as follows

  PDF_REPORT     PDF_DESCRIPTION
  IN002C                     STOCK FILE PURGE - PRINT WH CONTROL

  How can I cut the column data (log_hdr) to match column (pdf_report)?
  
  Any help will be much appreciated

  user11978142 wrote:
  Yes the code always starts with an alphabetic character and always ends before the underscore character and the prefix is always digital.

  And Yes to the second comment WRT 1 to many relationship.

  WRT the duplicates I want the info displayed even if there is no matching printpdf

  You talk a LEFT OUTER JOIN, then:

  See the example below (the statement are just to reproduce the paintings, just use the last query):

  WITH xpq_log AS
  (
     SELECT '0499SYS003A_06' log_hdr FROM DUAL UNION ALL
     SELECT '0612PV410W1_06' log_hdr FROM DUAL UNION ALL
     SELECT '0609IN002C_06' log_hdr FROM DUAL UNION ALL
     SELECT '2201PA100D1_30' log_hdr FROM DUAL
  )
  , printpdf AS
  (
     SELECT 'SYS003A' pdf_report, 'STOCK FILE PURGE - PRINT WH CONTROL' description FROM DUAL UNION ALL
     SELECT 'PV410W1' pdf_report, 'Description 2' description FROM DUAL
  )
  SELECT a.log_hdr, REGEXP_SUBSTR (a.log_hdr, '[[:alpha:]][^_]*') AS pdf_report
       , b.description
    FROM xpq_log a LEFT OUTER JOIN printpdf b
         ON pdf_report = REGEXP_SUBSTR (a.log_hdr, '[[:alpha:]][^_]*');
  
  Output:
  LOG_HDR        PDF_REPORT     DESCRIPTION
  -------------- -------------- -----------------------------------
  0499SYS003A_06 SYS003A        STOCK FILE PURGE - PRINT WH CONTROL
  0612PV410W1_06 PV410W1        Description 2
  2201PA100D1_30 PA100D1
  0609IN002C_06  IN002C                                           
  

  Kind regards.
  Al

• convert the varchar2 data type to the data number type

  How to convert the varchar2 data type to the data type number.
  
  
  It looks like my data
  
  create table one)
  col1 varchar2 (50)
  col2 varchar2 (500);
  
  Insert in a (col1, col2) values ('1234 ', ' 2345');
  
  Select Column1 of number (19)) cast (to_number (col1);
  
  IAM getting error invalid number
  
  
  I need to create a table with the same columns with data like number types (19)
  
  can someone help me
  
  Thank you

  You have changed your original post, so now I see that you get the invalid number.

  This is why you should always avoid the varchar columns to store numbers or dates...

  Since your table source contains a nonnumeric value, you can write a pl/sql to convert data and see what records are false:

  SQL> insert into a (col1,col2) values ('xxxx','2345');
  
  1 row created.
  
  SQL> select * from a;
  
  COL1     COL2
  -------- --------
  1234     2345
  xxxx     2345
  
  2 rows selected.
  
  SQL> create table b (col1 number(19), col2 number(19));
  
  Table created.
  
  SQL> set serverout on
  
  SQL> declare
    2  cursor c is
    3  select * from a;
    4  begin
    5    for r in c loop
    6     begin
    7       insert into b values (to_number(r.col1), to_number(r.col2));
    8     exception
    9       when invalid_number then
   10        dbms_output.put_line('Row rejected: col1='||r.col1||' col2='||r.col2);
   11     end;
   12    end loop;
   13  end;
   14  /
  Row rejected: col1=xxxx col2=2345
  
  PL/SQL procedure successfully completed.
  
  SQL> select * from b;
  
        COL1       COL2
  ---------- ----------
        1234       2345
  
  1 row selected.
  

  Max

  Published by: Massimo Ruocchio, June 14, 2011 20:00
  Added the first query in the example

• Database application - direct incorrect column data type

  Hello all-
  
  hope you can help with this. I use the live database request in Oracle BI to send a complex query directly to our data warehouse. My problem is that the columns of results containing my measurements are converted by Oracle BI so they should be double. The conversion of integer causes decimals to round values, reading to incorrect results in my reports. I tried several tweeks to my request to allow OBIEE correct estimate on the data type, but nothing has worked.
  
  Is there a way to force OBIEE to recognize the correct data type for a column in a query request to the live database?
  
  Thanks in advance for you help!
  
  Mac

  Click here for a solution using the cast function:
  http://gerardnico.com/wiki/dat/OBIEE/direct_database_request_table_function#oracle_number_data_type_as_an_integer

  See you soon
  Nico

• Using DBMS_DATAPUMP with the LONG data type

  I have a procedure below that calls the DBMS_DATAPUMP procedure using a REMOTE_LINK move a schema of one database to another. However, some tables in this schema have columns with the data type of LONG. And when I run it I get an error saying that you cannot move the data with the LONG data type using a REMOTE CONNECTION. So no data in these specific tables gets flying over.
  
  Does anyone else have this problem? If so, do you have a work around? I tried to add a CLOB column in my table and affecting the new CLOB equal THROUGHOUT, but I couldn't get that to not work either... even when I tried to use a TO_LOB. If I could get that pass, then I could just slide ALONG, the schema, and then re-create the LONG column on the opposite side.
  
  Here is my procedure...
  
  
  
  DECLARE
  / * IMPORT/EXPORT VARIABLES * /.
  v_dp_job_handle NUMBER;          -The handful of job data pump
  v_count NUMBER;          -Index of the loop
  v_percent_done NUMBER;          -Percentage of job complete
  v_job_state VARCHAR2 (30);     -To keep track of job status
  v_message KU$ _LOGENTRY;     -For error messages and work in PROGRESS
  v_job_status KU$ _JOBSTATUS;     -The State of the work of get_status
  v_status KU$ _STATUS;     -The status returned by get_status object
  v_logfile NUMBER;
  T_DATE VARCHAR2 (13).
  v_source_server_name VARCHAR2 (50);
  v_destination_server_name VARCHAR2 (50);
  
  BEGIN
  v_project: = 'TEST ';
  T_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_' | T_DATE,
  VERSION = > 'LAST');
  
  v_logfile: = DBMS_DATAPUMP. KU$ _FILE_TYPE_LOG_FILE;
  
  DBMS_DATAPUMP. ADD_FILE)
  MANAGE = > v_dp_job_handle,
  FILENAME = > v_project | ' _EXP_' | T_DATE |'. JOURNAL '.
  DIRECTORY = > 'DATAPUMP. "
  FILETYPE = > v_logfile);
  
  DBMS_DATAPUMP. () METADATA_FILTER
  MANAGE = > 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 ('* percent of the job 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. WORK IN PROGRESS;
  ELSIF BITAND (v_status.mask, DBMS_DATAPUMP. KU$ _STATUS_JOB_ERROR)! = 0 THEN
  v_message: = v_status. ERROR;
  ON THE OTHER
  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 (' State of the Final work = ' | v_job_state);
  
  DBMS_DATAPUMP. Detach (v_dp_job_handle);
  END;

  TO_LOB can be used to insert, create table in select and update the instructions to convert

  So: You simply cannot use it in SELECT..., you can use CREATE TABLE BLAH AS SELECT TO_LOB (LONG_COLUMN) OF DREADED_TABLE_WITH_LONG_COL;

• Error (21,100): PL/SQL: ORA-00997: illegal use of the LONG data type

  CREATE or REPLACE (name in varchar2) procedure Compress_tab_partition
  is
  last_mnth_var varchar2 (8);
  curr_mnth_var varchar2 (8);
  number of last_mnth;
  number of curr_mnth;
  last_partition varchar2 (8);
  high_val varchar2 (4000);
  Start

  Select to_char (add_months (trunc (sysdate, 'MM'),-1), 'YYYYMM') | ' 00' in the double last_mnth_var;
  Select to_char (sysdate, 'YYYY') | TO_CHAR (sysdate, 'mm') | ' 00' in the double curr_mnth_var;
  Select to_number (last_mnth_var) in the double last_mnth;
  Select to_number (curr_mnth_var) in the double curr_mnth;

  Dbms_output.put_line ('Compression of GOLDMGR Table scores.' | table-name |) "to go". ») ;
  Dbms_output.put_line(' ');

  / * Step 1 - identify the name of the partition of the specified table must be compressed * /.
  Select high_value from high_val from user_tab_partitions where table_name = table-name;
  Select nom_partition into last_partition from user_tab_partitions where table_name = table-name and high_value = rtrim (high_val);

  / * Step 2 - Alter partition table to compress * /.

  run immediately "ALTER TABLE GOLDMGR." | table_name | ' CHANGE THE PARTITION '. last_partition | "COMPRESS by low query";

  / * Step 3 - Index rebuild step * /.

  I'm in (select index_name in user_indexes where table_name = table-name)
  loop
  run immediately "ALTER INDEX GOLDMGR." | i.index_name |' REBUILD ";
  end loop;

  Dbms_output.put_line (' COMPLETED: compress the Table partitions change.) ") ;

  end;
  /

  I'm getting an error like: Error (21,100): PL/SQL: ORA-00997: illegal use of the LONG data type

  Please resolve.

  HIGH_VALUE datatype is LONG. You may not use for a long TIME in WHERE clause expressions. You need to loop through the partitions by selecting HIGH_VALUE and then comparing. Secondly, there is no need to select double to calculate expressions. For example:

  Select to_char (add_months (trunc (sysdate, 'MM'),-1), 'YYYYMM') | ' 00' in the double last_mnth_var;

  should be replaced by

  last_mnth_var: = to_char (add_months (trunc (sysdate, 'MM'),-1), 'YYYYMM') | ' 00'.

  and there is no need to add_months here:

  last_mnth_var: = to_char (trunc (sysdate, 'MM') - 1, "YYYYMM"). ' 00'.

  But the main question is simply ALTER TABLE MODIFY PARTITION COMPRESS allows compression but does not compress. You must issue ALTER TABLE MOVE PARTITION COMPRESS:

  SQL > create table tbl (n) partition by range (n)
  2 (partition p1 values less than (maxvalue))
  3. Select lpad('X',4000,'X') from dual connect by level<=>
  4.

  Table created.

  SQL > select bytes
  2 from WHERE user_segments
  3 where nom_segment = 'TBL '.
  4 and nom_partition = 'P1 '.
  5.

  BYTES
  ----------
  830472192

  SQL > alter table tbl
  2. change the partition p1 compress
  3.

  Modified table.

  SQL > select bytes
  2 from WHERE user_segments
  3 where nom_segment = 'TBL '.
  4 and nom_partition = 'P1 '.
  5.

  BYTES
  ----------
  830472192

  SQL > alter table tbl
  2. move the partition p1 compress
  3.

  Modified table.

  SQL > select bytes
  2 from WHERE user_segments
  3 where nom_segment = 'TBL '.
  4 and nom_partition = 'P1 '.
  5.

  BYTES
  ----------
  8388608

  SQL >

  SY.

• ORA-00997: illegal use of the LONG data type

  Hi all

  11.2.0.1

  ALTER TABLE SAFDB MOVE TABLESPACE DATA_TS_ENC

  *

  ERROR on line 1:

  ORA-00997: illegal use of the LONG data type

  Why illegal? How can I move this table?

  Thank you very much

  pK

  Take a look who

  http://aprakash.WordPress.com/2011/01/06/how-to-move-table-containing-long-or-LOB-columns/

  Concerning

• Largest number of digits for the NUMBER data type?

  What length more of a NUMBER that Oracle will "support"?

  The documentation says the following:

  Limitations of the data type says:

  «Can be represented in a comprehensive precision 38 digits»

  NUMBER of Data Types says:

  "Oracle guarantees portability of numbers with precision of up to 20 digits of base-100, which equals 39 or 40 decimal digits according to the position of the decimal point."

  I realize account that if I define a column as simply NUMBER, I can insert numbers with a size up to 126 characters.  However, Oracle seems to maintain only the first 40 digits in MOST cases.  The largest number of digits, it seems to allow is 40 before it begins to be replaced by 0.

  With numbers that have more than 40 figures, Oracle will sometimes replace all numbers according to the 38th numbers with a 0 and sometimes replace 0 after the digit 39th or 40th.

  Therefore, what is the largest number of digits, can be trusted to safely store Oracle?

  This is the code I used for this testing process.

  create the table max_num (num number);

  declare

  number of l_x;

  Start

  for x in 1.200

  loop

  l_x: = x;

  insert into max_num values (rpad (1, x, 1));

  end loop;

  exception

  while others then

  dbms_output.put_line ('STOP: ' | l_x);

  dbms_output.put_line (SQLERRM);

  end;

  /

  Select num, length (replace (num, 0)) of max_num;

  What length more of a NUMBER that Oracle will "support"?

  You have already given your own answer. If 'length': the maximum number of digits is written the doc gives you the answer:

  999... (38 9's) x 10 value maximum¹²⁵

  The 38/39/40, hereinafter referred to as the doc means "significant digits". This is why rounding or truncation occurs if you provide more significant digits of 38/39/40.

  Oracle stores the numbers internally in a binary format 21 bytes using a documented structure in the doc of the OIC in the section 'NUMBER'.

  http://docs.Oracle.com/CD/E11882_01/AppDev.112/e10646/oci03typ.htm#i423684

  Oracle database stores the values of the NUMBER data type in a variable length format. The first byte is the exponent and is followed by 1 to 20 mantissa bytes. The high bit of the exponent byte is the sign bit; It is defined for positive numbers, and it is cleared for negative numbers. The lower 7 bits represent the exponent, which is a number of base-100 with an offset of 65.

  This article from doc continues to show you how to convert the internal format to the real value.

  An additional byte of 1 is used for all types of data to store the length; That's why you often see docs saying numbers can take 22 bytes.

• ORA-02327: cannot create indexes on the LOB data type expression

  DB 10.2.0.4
  DB 5.2
  
  I am not able to move lobindex and lobsegment. While try occurs below error
  
  SQL > ALTER INDEX dev. "" SYS_IL0000718396C00002$ $"REBUILD THE TABLESPACE DATA_TEMP;
  ALTER INDEX dev. "" SYS_IL0000718396C00002$ $"REBUILD TABLESPACE DATA_TEMP
  *
  ERROR on line 1:
  ORA-02327: cannot create indexes on the LOB data type expression
  
  Thank you
  
  Published by: user13382934 on October 16, 2012 14:05

  correct syntax is
  ALTER TABLE.

  MOVE the LOB ()
  STORE AS (tablespace );

  Where is a name of the / columns LOB, not the name of the segment. Moving type LOB data will move its indexes as well.