Ora-01489: result of string concatenation is too long

Hello Gurus,
i have a typical problem
i am constructing a query in FORM and writing SQLPLUS script into a .SQL file. file will contain final data like below..
set linesize 90
set pagesize 0
set echo off
set verify off
set termout off
set feedback off
set trimspool on
set escape '^'
spool D:\10GAPPServerappln\xxx\TEMPREP\ADA39057.sql;
set linesize 229
select ' IQIS# ,Cust Complaint Short Txt ,CD Short Txt ' from dual;
set linesize 129
select a||','||b||','||c||d from table;
spool off;
exit;
After this By using HOST command i will execute the above .sql script and will write the output to text file.
But problem is when i have clob column in any one of concatenated columns in query (a or b or c) then i am getting the error "Ora-01489: result of string concatenation is too long".
pls suggest me how to overcome this problem..

sybrand_b wrote:
Obviously the || operator is concatenating strings, your CLOB is implicitly converted to a VARCHAR2, which has a 4000 bytes limit.???
From non-experts who did read documentation:
CLOB || VARCHAR2 = CLOB:
SQL> CREATE OR REPLACE
  2  VIEW V1
  3  AS SELECT TO_CLOB('A') || 'A' clob_concat_varchar2 FROM dual
  4  /
View created.
SQL> DESC V1
Name                                      Null?    Type
CLOB_CONCAT_VARCHAR2                               CLOB
SQL> SY.

Similar Messages

  • Connect by - sql help : getting error ORA-01489: result of string concatena

    here is an sql query and I am trying to cook a decode but since there are many columns invloved when I am trying to run this I am getting the following error:
    ORA-01489: result of string concatenation is too long
    Any kind of help is appreciated, I need to get this going otherwise I am dead :(
    Regards
    Rahul
    SQL:
    select sys_connect_by_path(c.decode_prep,'-') decode_prep
    from (select 'DECODE(BIAPPS_11.'||substr(b.all_cols,instr(b.all_cols,',',1,a.rn)+1,instr(b.all_cols,',',1,a.rn+1)-instr(b.all_cols,',',1,a.rn)-1)||','||'RAHULKALRA.'||substr(b.all_cols,instr(b.all_cols,',',1,a.rn)+1,instr(b.all_cols,',',1,a.rn+1)-instr(b.all_cols,',',1,a.rn)-1)||',''1'',''0'')' decode_prep, rownum curr, rownum -1 prev
    from (select rownum rn
    from dual connect by rownum <=
    (select (length('ROW_WID,COST_CENTER_NUM,COST_CENTER_NAME,COST_CENTER_DESC,CONTROL_AREA_NUM,CONTROL_AREA_NAME,CATEGORY_CODE,CATEGORY_NAME,CATEGORY_DESC,MANAGER_NAME,CURRENCY_CODE,CURRENCY_NAME,LANGUAGE_CODE,LANGUAGE_NAME,ST_ADDRESS1,ST_ADDRESS2,POST_OFFICE_BOX,CITY_NAME,STATE_CODE,STATE_NAME,REGION_CODE,REGION_NAME,COUNTRY_CODE,COUNTRY_NAME,POSTAL_CODE,PHONE_NUM,FAX_NUM,CSCN_HIER1_CODE,CSCN_HIER1_NAME,CSCN_HIER2_CODE,CSCN_HIER2_NAME,CSCN_HIER3_CODE,CSCN_HIER3_NAME,CSCN_HIER4_CODE,CSCN_HIER4_NAME,CSCN_HIER5_CODE,CSCN_HIER5_NAME,CSCN_HIER6_CODE,CSCN_HIER6_NAME,ACTIVE_FLG,CREATED_BY_WID,CHANGED_BY_WID,CREATED_ON_DT,CHANGED_ON_DT,AUX1_CHANGED_ON_DT,AUX2_CHANGED_ON_DT,AUX3_CHANGED_ON_DT,AUX4_CHANGED_ON_DT,SRC_EFF_FROM_DT,SRC_EFF_TO_DT,EFFECTIVE_FROM_DT,EFFECTIVE_TO_DT,DELETE_FLG,CURRENT_FLG,W_INSERT_DT,W_UPDATE_DT,DATASOURCE_NUM_ID,ETL_PROC_WID,INTEGRATION_ID,SET_ID,TENANT_ID,X_CUSTOM')
    - length(replace('ROW_WID,COST_CENTER_NUM,COST_CENTER_NAME,COST_CENTER_DESC,CONTROL_AREA_NUM,CONTROL_AREA_NAME,CATEGORY_CODE,CATEGORY_NAME,CATEGORY_DESC,MANAGER_NAME,CURRENCY_CODE,CURRENCY_NAME,LANGUAGE_CODE,LANGUAGE_NAME,ST_ADDRESS1,ST_ADDRESS2,POST_OFFICE_BOX,CITY_NAME,STATE_CODE,STATE_NAME,REGION_CODE,REGION_NAME,COUNTRY_CODE,COUNTRY_NAME,POSTAL_CODE,PHONE_NUM,FAX_NUM,CSCN_HIER1_CODE,CSCN_HIER1_NAME,CSCN_HIER2_CODE,CSCN_HIER2_NAME,CSCN_HIER3_CODE,CSCN_HIER3_NAME,CSCN_HIER4_CODE,CSCN_HIER4_NAME,CSCN_HIER5_CODE,CSCN_HIER5_NAME,CSCN_HIER6_CODE,CSCN_HIER6_NAME,ACTIVE_FLG,CREATED_BY_WID,CHANGED_BY_WID,CREATED_ON_DT,CHANGED_ON_DT,AUX1_CHANGED_ON_DT,AUX2_CHANGED_ON_DT,AUX3_CHANGED_ON_DT,AUX4_CHANGED_ON_DT,SRC_EFF_FROM_DT,SRC_EFF_TO_DT,EFFECTIVE_FROM_DT,EFFECTIVE_TO_DT,DELETE_FLG,CURRENT_FLG,W_INSERT_DT,W_UPDATE_DT,DATASOURCE_NUM_ID,ETL_PROC_WID,INTEGRATION_ID,SET_ID,TENANT_ID,X_CUSTOM',',')))+1 total_cols
    from dual)) a, (select ','||'ROW_WID,COST_CENTER_NUM,COST_CENTER_NAME,COST_CENTER_DESC,CONTROL_AREA_NUM,CONTROL_AREA_NAME,CATEGORY_CODE,CATEGORY_NAME,CATEGORY_DESC,MANAGER_NAME,CURRENCY_CODE,CURRENCY_NAME,LANGUAGE_CODE,LANGUAGE_NAME,ST_ADDRESS1,ST_ADDRESS2,POST_OFFICE_BOX,CITY_NAME,STATE_CODE,STATE_NAME,REGION_CODE,REGION_NAME,COUNTRY_CODE,COUNTRY_NAME,POSTAL_CODE,PHONE_NUM,FAX_NUM,CSCN_HIER1_CODE,CSCN_HIER1_NAME,CSCN_HIER2_CODE,CSCN_HIER2_NAME,CSCN_HIER3_CODE,CSCN_HIER3_NAME,CSCN_HIER4_CODE,CSCN_HIER4_NAME,CSCN_HIER5_CODE,CSCN_HIER5_NAME,CSCN_HIER6_CODE,CSCN_HIER6_NAME,ACTIVE_FLG,CREATED_BY_WID,CHANGED_BY_WID,CREATED_ON_DT,CHANGED_ON_DT,AUX1_CHANGED_ON_DT,AUX2_CHANGED_ON_DT,AUX3_CHANGED_ON_DT,AUX4_CHANGED_ON_DT,SRC_EFF_FROM_DT,SRC_EFF_TO_DT,EFFECTIVE_FROM_DT,EFFECTIVE_TO_DT,DELETE_FLG,CURRENT_FLG,W_INSERT_DT,W_UPDATE_DT,DATASOURCE_NUM_ID,ETL_PROC_WID,INTEGRATION_ID,SET_ID,TENANT_ID,X_CUSTOM'||',' all_cols from dual) b) c
    start with curr = 1
    connect by prior curr = prev
    order by length(sys_connect_by_path(c.decode_prep,'-')) desc
    same as above sql only difference is here I am pulling the first record from the result set which above query returns :
    select ltrim(replace(decode_prep,'-','||'),'||') decode_prep
    from (select sys_connect_by_path(c.decode_prep,'-') decode_prep
    from (select 'DECODE(BIAPPS_11.'||substr(b.all_cols,instr(b.all_cols,',',1,a.rn)+1,instr(b.all_cols,',',1,a.rn+1)-instr(b.all_cols,',',1,a.rn)-1)||','||'RAHULKALRA.'||substr(b.all_cols,instr(b.all_cols,',',1,a.rn)+1,instr(b.all_cols,',',1,a.rn+1)-instr(b.all_cols,',',1,a.rn)-1)||',''1'',''0'')' decode_prep, rownum curr, rownum -1 prev
    from (select rownum rn
    from dual connect by rownum <=
    (select (length('ROW_WID,COST_CENTER_NUM,COST_CENTER_NAME,COST_CENTER_DESC,CONTROL_AREA_NUM,CONTROL_AREA_NAME,CATEGORY_CODE,CATEGORY_NAME,CATEGORY_DESC,MANAGER_NAME,CURRENCY_CODE,CURRENCY_NAME,LANGUAGE_CODE,LANGUAGE_NAME,ST_ADDRESS1,ST_ADDRESS2,POST_OFFICE_BOX,CITY_NAME,STATE_CODE,STATE_NAME,REGION_CODE,REGION_NAME,COUNTRY_CODE,COUNTRY_NAME,POSTAL_CODE,PHONE_NUM,FAX_NUM,CSCN_HIER1_CODE,CSCN_HIER1_NAME,CSCN_HIER2_CODE,CSCN_HIER2_NAME,CSCN_HIER3_CODE,CSCN_HIER3_NAME,CSCN_HIER4_CODE,CSCN_HIER4_NAME,CSCN_HIER5_CODE,CSCN_HIER5_NAME,CSCN_HIER6_CODE,CSCN_HIER6_NAME,ACTIVE_FLG,CREATED_BY_WID,CHANGED_BY_WID,CREATED_ON_DT,CHANGED_ON_DT,AUX1_CHANGED_ON_DT,AUX2_CHANGED_ON_DT,AUX3_CHANGED_ON_DT,AUX4_CHANGED_ON_DT,SRC_EFF_FROM_DT,SRC_EFF_TO_DT,EFFECTIVE_FROM_DT,EFFECTIVE_TO_DT,DELETE_FLG,CURRENT_FLG,W_INSERT_DT,W_UPDATE_DT,DATASOURCE_NUM_ID,ETL_PROC_WID,INTEGRATION_ID,SET_ID,TENANT_ID,X_CUSTOM')
    - length(replace('ROW_WID,COST_CENTER_NUM,COST_CENTER_NAME,COST_CENTER_DESC,CONTROL_AREA_NUM,CONTROL_AREA_NAME,CATEGORY_CODE,CATEGORY_NAME,CATEGORY_DESC,MANAGER_NAME,CURRENCY_CODE,CURRENCY_NAME,LANGUAGE_CODE,LANGUAGE_NAME,ST_ADDRESS1,ST_ADDRESS2,POST_OFFICE_BOX,CITY_NAME,STATE_CODE,STATE_NAME,REGION_CODE,REGION_NAME,COUNTRY_CODE,COUNTRY_NAME,POSTAL_CODE,PHONE_NUM,FAX_NUM,CSCN_HIER1_CODE,CSCN_HIER1_NAME,CSCN_HIER2_CODE,CSCN_HIER2_NAME,CSCN_HIER3_CODE,CSCN_HIER3_NAME,CSCN_HIER4_CODE,CSCN_HIER4_NAME,CSCN_HIER5_CODE,CSCN_HIER5_NAME,CSCN_HIER6_CODE,CSCN_HIER6_NAME,ACTIVE_FLG,CREATED_BY_WID,CHANGED_BY_WID,CREATED_ON_DT,CHANGED_ON_DT,AUX1_CHANGED_ON_DT,AUX2_CHANGED_ON_DT,AUX3_CHANGED_ON_DT,AUX4_CHANGED_ON_DT,SRC_EFF_FROM_DT,SRC_EFF_TO_DT,EFFECTIVE_FROM_DT,EFFECTIVE_TO_DT,DELETE_FLG,CURRENT_FLG,W_INSERT_DT,W_UPDATE_DT,DATASOURCE_NUM_ID,ETL_PROC_WID,INTEGRATION_ID,SET_ID,TENANT_ID,X_CUSTOM',',')))+1 total_cols
    from dual)) a, (select ','||'ROW_WID,COST_CENTER_NUM,COST_CENTER_NAME,COST_CENTER_DESC,CONTROL_AREA_NUM,CONTROL_AREA_NAME,CATEGORY_CODE,CATEGORY_NAME,CATEGORY_DESC,MANAGER_NAME,CURRENCY_CODE,CURRENCY_NAME,LANGUAGE_CODE,LANGUAGE_NAME,ST_ADDRESS1,ST_ADDRESS2,POST_OFFICE_BOX,CITY_NAME,STATE_CODE,STATE_NAME,REGION_CODE,REGION_NAME,COUNTRY_CODE,COUNTRY_NAME,POSTAL_CODE,PHONE_NUM,FAX_NUM,CSCN_HIER1_CODE,CSCN_HIER1_NAME,CSCN_HIER2_CODE,CSCN_HIER2_NAME,CSCN_HIER3_CODE,CSCN_HIER3_NAME,CSCN_HIER4_CODE,CSCN_HIER4_NAME,CSCN_HIER5_CODE,CSCN_HIER5_NAME,CSCN_HIER6_CODE,CSCN_HIER6_NAME,ACTIVE_FLG,CREATED_BY_WID,CHANGED_BY_WID,CREATED_ON_DT,CHANGED_ON_DT,AUX1_CHANGED_ON_DT,AUX2_CHANGED_ON_DT,AUX3_CHANGED_ON_DT,AUX4_CHANGED_ON_DT,SRC_EFF_FROM_DT,SRC_EFF_TO_DT,EFFECTIVE_FROM_DT,EFFECTIVE_TO_DT,DELETE_FLG,CURRENT_FLG,W_INSERT_DT,W_UPDATE_DT,DATASOURCE_NUM_ID,ETL_PROC_WID,INTEGRATION_ID,SET_ID,TENANT_ID,X_CUSTOM'||',' all_cols from dual) b) c
    start with curr = 1
    connect by prior curr = prev
    order by length(sys_connect_by_path(c.decode_prep,'-')) desc)
    where rownum = 1
    Edited by: Mac_Freak_Rahul on Nov 28, 2012 1:31 AM : in the first sql ')'
    removed after desc in the last line so now this query will run and throw an error.

    Clearly your error is because the string concatenation you are doing with sys_connect_by_path is exceeding the 4000 bytes permitted by SQL.
    In that case you need to concatenate your data into a CLOB datatype, for which you'll need a CLOB aggregation function...
    create or replace type clobagg_type as object
      text clob,
      static function ODCIAggregateInitialize(sctx in out clobagg_type) return number,
      member function ODCIAggregateIterate(self in out clobagg_type, value in clob) return number,
      member function ODCIAggregateTerminate(self in clobagg_type, returnvalue out clob, flags in number) return number,
      member function ODCIAggregateMerge(self in out clobagg_type, ctx2 in clobagg_type) return number
    create or replace type body clobagg_type is
      static function ODCIAggregateInitialize(sctx in out clobagg_type) return number is
      begin
        sctx := clobagg_type(null) ;
        return ODCIConst.Success ;
      end;
      member function ODCIAggregateIterate(self in out clobagg_type, value in clob) return number is
      begin
        self.text := self.text || value ;
        return ODCIConst.Success;
      end;
      member function ODCIAggregateTerminate(self in clobagg_type, returnvalue out clob, flags in number) return number is
      begin
        returnValue := self.text;
        return ODCIConst.Success;
      end;
      member function ODCIAggregateMerge(self in out clobagg_type, ctx2 in clobagg_type) return number is
      begin
        self.text := self.text || ctx2.text;
        return ODCIConst.Success;
      end;
    end;
    create or replace function clobagg(input clob) return clob
      deterministic
      parallel_enable
      aggregate using clobagg_type;
    SQL> select trim(',' from clobagg(ename||',')) as enames from emp;
    ENAMES
    SMITH,ALLEN,WARD,JONES,MARTIN,BLAKE,CLARK,SCOTT,KING,TURNER,ADAMS,JAMES,FORD,MILLER
    SQL> ed
    Wrote file afiedt.buf
      1  with t as
      2    (select 'PFL' c1, 0 c2,110 c3 from dual union all
      3     select 'LHL', 0 ,111 from dual union all
      4     select 'PHL', 1, 111 from dual union all
      5     select 'CHL', 2, 111 from dual union all
      6     select 'DHL', 0, 112 from dual union all
      7     select 'VHL', 1, 112 from dual union all
      8     select 'CPHL', 0, 114 from dual union all
      9     select 'WDCL', 1, 114 from dual union all
    10     select 'AHL' ,2 ,114 from dual union all
    11     select 'NFDL', 3, 114 from dual)
    12  --
    13  -- end of test data
    14  --
    15  select trim(clobagg(c1||' ')) as c1, c3
    16  from (select * from t order by c3, c2)
    17  group by c3
    18* order by c3
    SQL> /
    C1                                     C3
    PFL                                   110
    LHL CHL PHL                           111
    DHL VHL                               112
    CPHL AHL NFDL WDCL                    114

  • Unexpected "result of the string concatenation is too long" error

    Hello,
    I am using Oracle Database 11.2.0.
    When querying my database with a common table expression which concatenates VARCHAR2 strings, I receive an ORA-01489 error although I'm doubting that I am concatenating more than 4000 characters.
    To be more precise, I have a table entity which basically stores XML elements including their parent element and their sibling position among its siblings. The CREATE statement for this table is listed below.
    CREATE TABLE Entity (
    ID NUMBER(10,0) NOT NULL PRIMARY KEY,
    Name VARCHAR2(100) NOT NULL,
    Parent NUMBER(10,0) REFERENCES Entity(ID),
    Sibling_Pos NUMBER(2,0) DEFAULT 0
    Now, I would like for all elements to be concatenated with their ancestor elements to a structure like this:
    "/root_element(sibling_pos)/.../ancestor_element(sibling_pos)/parent_element(sibling_pos)/current_element(sibling_pos)"
    (where root_element, ancestor_element, parent_element and current_element are just values from the name column of the entity table)
    In order to achieve this, I use a common table expression which concatenates the name and sibling_pos values as shown below:
    WITH entity_cte (lvl, id, path) AS (
    SELECT 1 AS lvl, id, '/' || name || '(0' || sibling_pos || ')' AS path
    FROM entity
    WHERE parent IS NULL
    UNION ALL (
    SELECT lvl + 1 AS lvl, e.id, entity_cte.path || '/' || e.name || '(' || cast(e.sibling_pos AS VARCHAR2(2)) || ')' AS path
    FROM entity_cte, entity e
    WHERE entity_cte.id = e.parent
    SELECT lvl, id, path
    FROM entity_cte e
    After inserting certain values, I get the ORA-01489 error, that the result of the string concatenation is too long. The maximum is referred to as being 4000 characters for VARCHAR2 in the oracle documentation and in various websites. Of course, it is clear to me by just using the common table expression like that, I could run into such an error. However, due to the structure of my XML documents, I doubted that the resulting strings would be more than 4000 characters long.
    So, I rearranged my query in order to count the characters to be concatenated instead of actually concatenating them. The query is stated below as well, the changes are marked bold:
    WITH entity_cte (lvl, id, path) AS (
    SELECT 1 AS lvl, id, length('/' || name ||  '(0' || sibling_pos || ')') AS path
    FROM entity
    WHERE parent IS NULL
    UNION ALL (
    SELECT lvl + 1 AS lvl, e.id, entity_cte.path + length('/' || e.name || '(' || cast(e.sibling_pos AS VARCHAR2(2)) || ')') AS path
    FROM entity_cte, entity e
    WHERE entity_cte.id = e.parent
    SELECT lvl, id, path
    FROM entity_cte e
    ORDER BY path DESC
    The result of the query gives me a maximum length of 319 characters.
    To be sure, I also checked the maximum level depth (indicated by the column named lvl in the common table expression), meaning the maximum number of elements in my path (the concatenated string). The result is 18. As I use VARCHAR2(100) for the name column and add 5 charcaters in each level, the maximum number of characters expected for 18 levels would be 1890.
    So, now I wonder is the ORA-01489 maybe raised for another reason? Or is there something else I am missing?
    Any help would be appreciated. Further suggestions to track down the error are more than welcome. Thanks in advance.

    Thanks for the hint, BluShadow.
    Still, I don't reach that limit of 1000 characters with my actual data (yet). I understand that if my data changes, I might run into that error with the given query. But I don't understand why this error is raised with the given data I have. The longest string in the column "name" is 32 characters long up to now. When I'm adding 5 characters on each level and I only have max 18 levels that should only result in max 2664 bytes.
    @odie_63
    The database characterset is: AL32UTF8. If I googled correctly, than it just confirms what BluShadow said, that one character is represented by max 4 byte.
    Regarding the sample data, the XML document that I am inserting and which causes the error comprises 1058 nodes. That means I have 1058 entries in my entity table. I think it would be no sense posting all of it here, but is there a way that I can attach a text file containing an insert script to this post?
    Some sample data from the entity table orderd by the length of the string in the name column are shown below.
    "ID"     "NAME"     "TYPE"     "PARENT"     "SIBLING_POS"
    90     "representedCustodianOrganization"     1     89     0
    109     "serviceProviderOrganization"     1     108     0
    58     "standardIndustryClassCode"     1     55     2
    186     "standardIndustryClassCode"     1     173     7
    150     "standardIndustryClassCode"     1     137     7
    106     "dischargeDispositionCode"     1     99     4
    35     "administrativeGenderCode"     1     29     3
    932     "substanceAdministration"     1     931     0
    950     "substanceAdministration"     1     949     0
    1043     "representedOrganization"     1     1041     1
    71     "representedOrganization"     1     61     6
    137     "representedOrganization"     1     128     5
    173     "representedOrganization"     1     163     6
    504     "substanceAdministration"     1     503     0
    223     "representedOrganization"     1     221     1
    252     "representedOrganization"     1     250     1
    272     "representedOrganization"     1     270     1
    477     "substanceAdministration"     1     476     0
    481     "manufacturedLabeledDrug"     1     480     0
    207     "representedOrganization"     1     205     1
    802     "specimenPlayingEntity"     1     801     0
    830     "specimenPlayingEntity"     1     829     0
    844     "specimenPlayingEntity"     1     843     0
    858     "specimenPlayingEntity"     1     857     0
    99     "encompassingEncounter"     1     98     0
    788     "specimenPlayingEntity"     1     787     0
    676     "specimenPlayingEntity"     1     675     0
    704     "specimenPlayingEntity"     1     703     0
    718     "specimenPlayingEntity"     1     717     0
    746     "specimenPlayingEntity"     1     745     0
    Any help or further suggestion are appreciated. Thank you.

  • My string URL is too long and my servlet don't work.

    I need to call servlet from my web page but it does not work because My string URL is too long (appear message in my web "server not found"), exists a way to solve this?

    It's good that you have a solution. But your solution suggests that your original problem was not that the URL was too long, since you are still using GET. Probably it was something else. But at least you have a solution.

  • String literal too long error while invoking a package with clob variable

    I have a package.One of the input variables of the procedure in packae is clob.
    I want to invoke this package with a huge clob as input.
    when i invoke this package like that i am getting following error
    PLS-00172 string literal too long
    can't we pass clob(huge clob) as input .is there any solution for that ?
    Thanks
    Pramod Garre

    842802 wrote:
    If insert this data into a table , from sql prompt still i get the same error.Do you mean SQL*Plus? Then there is buffer limitation and it is better to split literal into, let say 1000 character chunks:
    SQL*Plus: Release 10.2.0.4.0 - Production on Tue Mar 29 16:17:26 2011
    Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.
    Connected to:
    Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    SQL> select 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' ||
      2  'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' ||
      3  'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' ||
      4  'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' ||
      5  'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
      6  from dual;
    from dual
    ERROR at line 6:
    ORA-01489: result of string concatenation is too long
    SQL> select to_clob('AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA') ||
      2  'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' ||
      3  'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' ||
      4  'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' ||
      5  'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
      6  from dual;
    TO_CLOB('AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    SQL> SY.

  • ORA-01489 Received Generating SQL for Report Region

    I am new to Apex and I am running into an issue with an report region I am puzzled by. Just a foreword, I'm sure this hack solution will get a good share of facepalms and chuckles from those with far more experience. I welcome suggestions and criticism that are helpful and edifying!
    I am on Apex 4.0.2.00.07 running on 10g, I believe R2.
    A little background, my customer has asked an Excel spreadsheet be converted into a database application. As part of the transition they would like an export from the database that is in the same format as the current spreadsheet. Because the column count in this export is dynmic based on the number of records in a specific table, I decided to create a temporary table for the export. The column names in this temp table are based on a "name" column from the same data table so I end up with columns named 'REC_NAME A', 'REC_NAME B', etc. (e.g. Alpha Record, Papa Record, Echo Record, X-Ray Record). The column count is currently ~350 for the spreadsheet version.
    Because the column count is so large and the column names are dynamic I've run into a host of challenges and errors creating this export. I am a contractor in a corporate environmentm, so making changes to the apex environment or installation is beyond my influence and really beyond what could be justified by this single requirement for this project. I have tried procedures and apex plug-ins for generating the file however the UTL_FILE package is not available to me. I am currently generating the SQL for the query in a function and returning it to the report region in a single column (the user will be doing a text-to-column conversion later). The data is successfully being generated, however, the sql for the headers is where I am stumped.
    At first I thought it was because I returned both queries as one and they were joined with a 'union all'. However, after looking closer, the SQL being returned for the headers is about +10K+ characters long. The SQL being returned for the data is about +14k+. As mentioned above, the data is being generated and exported, however when I generate the SQL for the headers I am receiving a report error with "ORA-01489: result of string concatenation is too long" in the file. I am puzzled why a shorter string is generating this message. I took the function from both pages and ran them in a SQL command prompt and both return their string values without errors.
    I'm hopeful that it's something obvious and noobish that I'm overlooking.
    here is the code:
    data SQL function:
    declare
      l_tbl varchar2(20);
      l_ret varchar2(32767);
      l_c number := 0;
      l_dlim varchar2(3) := '''|''';
    begin
      l_tbl := 'EXPORT_STEP';
      l_ret := 'select ';
      for rec in (select column_name from user_tab_columns where table_name = l_tbl order by column_id)
      loop
        if l_c = 1 then
            l_ret := l_ret || '||' || l_dlim || '|| to_char("'||rec.column_name||'")';
        else
            l_c := 1;
            l_ret := l_ret || ' to_char("' || rec.column_name || '")';
        end if;
      end loop;
        l_ret := l_ret || ' from ' || l_tbl;
      dbms_output.put_line(l_ret);
    end;header sql function:
    declare
      l_tbl varchar2(20);
      l_ret varchar2(32767);
      l_c number := 0;
      l_dlim varchar2(3) := '''|''';
    begin
      l_tbl := 'EXPORT_STEP';
      for rec in (select column_name from user_tab_columns where table_name = l_tbl order by column_id)
      loop
        if l_c = 1 then
            l_ret := l_ret || '||' || l_dlim || '||'''||rec.column_name||'''';
        else
            l_c := 1;
            l_ret := l_ret || '''' || rec.column_name || '''';
        end if;
      end loop;
        l_ret := l_ret || ' from dual';
      dbms_output.put_line(l_ret);
    end;-------
    EDIT: just a comment on the complexity of this export, each record in the back-end table adds 12 columns to my export table. Those 12 columns are coming from 5 different tables and are the product of a set of functions calculating or looking up their values. This is export is really a pivot table based on the records in another table.
    Edited by: nimda xinu on Mar 8, 2013 1:28 PM

    Thank you, Denes, for looking into my issue. I appreciate your time!
    It is unfortunately a business requirement. My customer has required that the data we are migrating to this app from a spreadsheet be exported in the same format, albeit temporarily. I still must meet the requirement. I'm working around the 350 columns by dumping everything into a single column, which is working for the data, however, the headers export is throwing the 01489 error. I did run into the error you posted in your reply. I attempted to work around it with the clob type but eneded up running into my string concatentation error again.
    I'm open to any suggestions at this point given that I have the data. I'm so close because the data is exporting, but because the columns are dynamic, the export does me little good without the headers to go along with it.

  • SQL command running into error: ora-01489

    Hello everyone,
    i have created a query as shown below. When i am trying to run this query on test server using TOAD it executes without any error.
    The same query i am trying to copy and paste on TOAD for my production server and it gives me an error:
    ORA-01489: result of string concatenation is too long
    select payslip_of_month,
    person_id, payslip_date, element_name,
    pay_action, business_group_id, payroll_desc,payment_currency,LISTAGG(screen_entry_value, ' ') WITHIN GROUP (ORDER BY display_sequence) AS ENTRIES_RESULT
    from (
    SELECT piv.display_sequence,piv.input_value_id,TO_CHAR (pact.effective_date, 'Month RRRR') payslip_of_month,
    per.person_id person_id,
    CASE
    WHEN pact.action_type <> 'Q'
    THEN TO_CHAR (pact.effective_date,'DD-MON-RRRR')
    ELSE TO_CHAR (NVL (pact.pay_advice_date, pact.DATE_EARNED),'DD-MON-RRRR')
    END payslip_date,
    NVL (pettl.reporting_name, pettl.element_name) element_name,
    trim(peev.screen_entry_value) screen_entry_value,pact.action_type pay_action, per.business_group_id,
    CASE
    WHEN has.assignment_set_name LIKE '%MAINRUN%'
    THEN 'End of Month Payment'
    WHEN pact.action_type = 'Q'
    THEN 'Request Payment'
    ELSE 'Adjustment Payment'
    END payroll_desc,
    pet.output_currency_code payment_currency
    FROM pay_element_types_f_tl pettl,
    pay_element_classifications_tl pectl,
    pay_element_types_f pet,
    pay_element_classifications pec,
    pay_input_values_f piv,
    pay_assignment_actions asact,
    pay_payroll_actions pact,
    per_abs_attendance_types_v ABS,
    per_all_assignments_f ass,
    per_all_people_f per,
    fnd_lookup_values fnd,
    hr_assignment_sets has ,
    pay_element_entry_values_f peev
    WHERE pectl.classification_id = pec.classification_id
    AND pectl.LANGUAGE = USERENV ('LANG')
    AND pettl.element_type_id = pet.element_type_id
    AND pettl.LANGUAGE = USERENV ('LANG')
    AND pact.payroll_action_id = asact.payroll_action_id
    AND pet.classification_id = pec.classification_id
    AND piv.element_type_id = pet.element_type_id
    AND piv.element_type_id = ABS.element_type_id(+)
    AND asact.assignment_id = ass.assignment_id
    AND ass.person_id = per.person_id
    and piv.name in ('Remarks1')
    AND SYSDATE BETWEEN ass.effective_start_date AND ass.effective_end_date
    AND SYSDATE BETWEEN per.effective_start_date AND per.effective_end_date
    AND pact.effective_date BETWEEN piv.effective_start_date
    AND piv.effective_end_date
    AND pact.effective_date BETWEEN pet.effective_start_date
    AND pet.effective_end_date
    AND fnd.lookup_code = pact.action_type
    AND fnd.lookup_type = 'ACTION_TYPE'
    AND pact.assignment_set_id = has.assignment_set_id(+)
    AND pettl.element_name = 'Payslip Remarks'
    and piv.input_value_id =peev.input_value_id
    and pact.effective_date between peev.EFFECTIVE_START_DATE and peev.EFFECTIVE_END_DATE
    order by piv.display_sequence)
    where PERSON_ID=:per_id
    and PAYSLIP_DATE like '%APR%2013%'
    and BUSINESS_GROUP_ID=0
    group by payslip_of_month, person_id, payslip_date, element_name,pay_action, business_group_id, payroll_desc,payment_currency
    Strange! I am unable to understand that the data entry done on both servers is same yet on one server it works fine however on the production server it fails.
    Pls help.
    thnx

    Hallo,
    you can replace the listagg command with screen_entry_value only and see if the data set is the same.
    regards
    Giuseppe

  • ORA-01489 sys_connect_by_path and previous solution not working

    Hi all.
    Oracle version:
    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
    PL/SQL Release 11.2.0.1.0 - Production
    "CORE     11.2.0.1.0     Production"
    TNS for Linux: Version 11.2.0.1.0 - Production
    NLSRTL Version 11.2.0.1.0 - Production
    I need to get routes in a map and the associated sum of distances from some point to another.
    map
    --     9
      F ----------E
      | \         |
      |  \2       |6
      |   \   11  |
    14|   C-------D
      |  / \10   /
      | /9  \   /15
      |/     \ /
      A-------B
         7I have a query that correctly gets the routes.
    WITH distances AS
         SELECT 'A' n1, 'B' n2, 7 d FROM DUAL UNION
         SELECT 'A' n1, 'C' n2, 9 d FROM DUAL UNION
         SELECT 'A' n1, 'F' n2, 14 d FROM DUAL UNION
         SELECT 'B' n1, 'D' n2, 15 d FROM DUAL UNION
         SELECT 'B' n1, 'C' n2, 10 d FROM DUAL UNION
         SELECT 'C' n1, 'D' n2, 11 d FROM DUAL UNION
         SELECT 'C' n1, 'F' n2, 2 d FROM DUAL UNION
         SELECT 'D' n1, 'E' n2, 6 d FROM DUAL UNION
         SELECT 'F' n1, 'E' n2, 9 d FROM DUAL
    SELECT
         'A'||sys_connect_by_path(n2,'-') path,
         SUBSTR(sys_connect_by_path(d,'+'),2) sum_dist
    FROM distances
    START WITH n1='A'
    CONNECT BY NOCYCLE PRIOR n2=n1;
    A-B          7
    A-B-C          7+10
    A-B-C-D          7+10+11
    A-B-C-D-E     7+10+11+6
    A-B-C-F          7+10+2
    A-B-C-F-E     7+10+2+9
    A-B-D          7+15
    A-B-D-E          7+15+6
    A-C          9
    A-C-D          9+11
    A-C-D-E          9+11+6
    A-C-F          9+2
    A-C-F-E          9+2+9
    A-F          14
    A-F-E          14+9The problem is when there are a lot of nodes, I get an ORA-01489: result of string concatenation is too long.
    I followed this link.
    sys_connect_by_path & to_CLOB
    I built the specified package but apparently is combining elements.
    If it's called just one time.
    WITH distances AS
         SELECT 'A' n1, 'B' n2, 7 d FROM DUAL UNION
         SELECT 'A' n1, 'C' n2, 9 d FROM DUAL UNION
         SELECT 'A' n1, 'F' n2, 14 d FROM DUAL UNION
         SELECT 'B' n1, 'D' n2, 15 d FROM DUAL UNION
         SELECT 'B' n1, 'C' n2, 10 d FROM DUAL UNION
         SELECT 'C' n1, 'D' n2, 11 d FROM DUAL UNION
         SELECT 'C' n1, 'F' n2, 2 d FROM DUAL UNION
         SELECT 'D' n1, 'E' n2, 6 d FROM DUAL UNION
         SELECT 'F' n1, 'E' n2, 9 d FROM DUAL
    SELECT
         'A'||'-'||hierarchy.branch(LEVEL,n2,'-') path
    FROM distances
    START WITH n1='A'
    CONNECT BY NOCYCLE PRIOR n2=n1;
    A-B
    A-B-C
    A-B-C-D
    A-B-C-D-E
    A-B-C-F
    A-B-C-F-E
    A-B-D
    A-B-D-E
    A-C
    A-C-D
    A-C-D-E
    A-C-F
    A-C-F-E
    A-FBut if I call it twice in the same query...
    WITH distances AS
         SELECT 'A' n1, 'B' n2, 7 d FROM DUAL UNION
         SELECT 'A' n1, 'C' n2, 9 d FROM DUAL UNION
         SELECT 'A' n1, 'F' n2, 14 d FROM DUAL UNION
         SELECT 'B' n1, 'D' n2, 15 d FROM DUAL UNION
         SELECT 'B' n1, 'C' n2, 10 d FROM DUAL UNION
         SELECT 'C' n1, 'D' n2, 11 d FROM DUAL UNION
         SELECT 'C' n1, 'F' n2, 2 d FROM DUAL UNION
         SELECT 'D' n1, 'E' n2, 6 d FROM DUAL UNION
         SELECT 'F' n1, 'E' n2, 9 d FROM DUAL
    SELECT
         'A'||SUBSTR(hierarchy.branch(LEVEL,n2,'-'),2) path,
         hierarchy.branch(LEVEL,d,'+') sum_dist
    FROM distances
    START WITH n1='A'
    CONNECT BY NOCYCLE PRIOR n2=n1;
    A          7
    A-C          7+10
    A-10-D          7+10+11
    A-10-11-E     7+10+11+6
    A-10-F          7+10+2
    A-10-2-E     7+10+2+9
    A-D          7+15
    A-15-E          7+15+6
    A          9
    A-D          9+11
    A-11-E          9+11+6
    A-F          9+2
    A-2-E          9+2+9As you can see, is combining the elements (A-10-11-E) node - distance - distance - node
    Do I have to create separate functions in the package, one per column?, or is there another way to solve this problem?, or even better, another way to solve the original problem (ORA-01489)
    Thanks a lot.
    Regards.
    Package code (by Solomon Yakobson):
    CREATE OR REPLACE
      PACKAGE Hierarchy
        IS
            TYPE BranchTableVarchar2Type IS TABLE OF VARCHAR2(4000)
              INDEX BY BINARY_INTEGER;
            BranchTableVarchar2 BranchTableVarchar2Type;
            TYPE BranchTableClobType IS TABLE OF CLOB
              INDEX BY BINARY_INTEGER;
            BranchTableClob BranchTableClobType;
            FUNCTION Branch(
                            p_Level          IN NUMBER,
                            p_Value          IN VARCHAR2,
                            p_Delimiter      IN VARCHAR2 DEFAULT CHR(0)
              RETURN VARCHAR2;
            PRAGMA RESTRICT_REFERENCES(Branch,WNDS);
            FUNCTION Branch(
                            p_Level          IN NUMBER,
                            p_Value          IN CLOB,
                            p_Delimiter      IN VARCHAR2 DEFAULT CHR(0)
              RETURN CLOB;
            PRAGMA RESTRICT_REFERENCES(Branch,WNDS);
    END Hierarchy;
    CREATE OR REPLACE
      PACKAGE BODY Hierarchy
        IS
            ReturnValueVarchar2 VARCHAR2(4000);
            ReturnValueClob     CLOB;
        FUNCTION Branch(
                        p_Level        IN NUMBER,
                        p_Value        IN VARCHAR2,
                        p_Delimiter    IN VARCHAR2 DEFAULT CHR(0)
          RETURN VARCHAR2
          IS
          BEGIN
              BranchTableVarchar2(p_Level) := p_Value;
              ReturnValueVarchar2          := p_Value;
              FOR I IN REVERSE 1..p_Level - 1 LOOP
                ReturnValueVarchar2 := BranchTableVarchar2(I)|| p_Delimiter || ReturnValueVarchar2;
              END LOOP;
              RETURN ReturnValueVarchar2;
        END Branch;
        FUNCTION Branch(
                        p_Level        IN NUMBER,
                        p_Value        IN CLOB,
                        p_Delimiter    IN VARCHAR2 DEFAULT CHR(0)
          RETURN CLOB
          IS
          BEGIN
              BranchTableClob(p_Level) := p_Value;
              ReturnValueClob          := p_Value;
              FOR I IN REVERSE 1..p_Level - 1 LOOP
                ReturnValueClob := BranchTableClob(I)|| p_Delimiter || ReturnValueClob;
              END LOOP;
              RETURN ReturnValueClob;
        END Branch;
    END Hierarchy;
    /Edited by: sKr on 08-mar-2012 17:29
    Package code added

    Hi,
    sKr wrote:
    Hi all.
    Oracle version:
    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
    PL/SQL Release 11.2.0.1.0 - Production
    "CORE     11.2.0.1.0     Production"
    TNS for Linux: Version 11.2.0.1.0 - Production
    NLSRTL Version 11.2.0.1.0 - Production
    I need to get routes in a map and the associated sum of distances from some point to another.
    map
    --     9
    F ----------E
    | \         |
    |  \2       |6
    |   \   11  |
    14|   C-------D
    |  / \10   /
    | /9  \   /15
    |/     \ /
    A-------B
    7... I wish we could mark questions as "Helpful" or "Correct". You'd get 10 points for sure.
    Do I have to create separate functions in the package, one per column?,You don't need separate functions. One user-defined function should be enough, just like one built-in version of SYS_CONNECT_BY_PATH is enough. Whatever it has to store internally, it knows to keep a separate copy for every argument that you call it with. The problem with the package, as originally posted, is that there's only one internal variable BranchTableVarchar2. Instead of one variable, make an array of similar variables, and add an optional argument to the branch funtion to tell it which element in that array to use.
    CREATE OR REPLACE
      PACKAGE Hierarchy
        IS
            TYPE BranchTableVarchar2Type IS TABLE OF VARCHAR2(4000)
              INDEX BY BINARY_INTEGER;
            BranchTableVarchar2 BranchTableVarchar2Type;
         TYPE VList     IS TABLE OF BranchTableVarchar2Type          -- ***  NEW  ***
           INDEX BY     BINARY_INTEGER;                         -- ***  NEW  ***
         vl     VList;                                      -- ***  NEW  ***
            TYPE BranchTableClobType IS TABLE OF CLOB
              INDEX BY BINARY_INTEGER;
            BranchTableClob BranchTableClobType;
            FUNCTION Branch(
                            p_Level          IN NUMBER,
                            p_Value          IN VARCHAR2,
                            p_Delimiter      IN VARCHAR2     DEFAULT CHR(0),
                   p_PathNum      IN PLS_INTEGER     DEFAULT     1     -- ***  NEW  ***
              RETURN VARCHAR2;
            PRAGMA RESTRICT_REFERENCES(Branch,WNDS);
            FUNCTION Branch(
                            p_Level          IN NUMBER,
                            p_Value          IN CLOB,
                            p_Delimiter      IN VARCHAR2 DEFAULT CHR(0)
              RETURN CLOB;
            PRAGMA RESTRICT_REFERENCES(Branch,WNDS);
    END Hierarchy;
    SHOW ERRORS
    PROMPT     ==========  FK BODY  ==========
    CREATE OR REPLACE
      PACKAGE BODY Hierarchy
        IS
            ReturnValueVarchar2 VARCHAR2(4000);
            ReturnValueClob     CLOB;
        FUNCTION Branch(
                        p_Level        IN NUMBER,
                        p_Value        IN VARCHAR2,
                        p_Delimiter    IN VARCHAR2       DEFAULT CHR(0),
                  p_PathNum        IN PLS_INTEGER DEFAULT 1     -- ***  NEW  ***
          RETURN VARCHAR2
          IS
          BEGIN
              vl (p_PathNum) (p_Level) := p_Value;               -- ***  CHANGED  ***
              ReturnValueVarchar2          := p_Value;
              FOR I IN REVERSE 1..p_Level - 1 LOOP
                ReturnValueVarchar2 := vl (p_PathNum) (I)          -- ***  CHANGED  ***
                             || p_Delimiter
                         || ReturnValueVarchar2;
              END LOOP;
              RETURN ReturnValueVarchar2;
        END Branch;
        FUNCTION Branch(
                        p_Level        IN NUMBER,
                        p_Value        IN CLOB,
                        p_Delimiter    IN VARCHAR2 DEFAULT CHR(0)
          RETURN CLOB
          IS
          BEGIN
              BranchTableClob(p_Level) := p_Value;
              ReturnValueClob          := p_Value;
              FOR I IN REVERSE 1..p_Level - 1 LOOP
                ReturnValueClob := BranchTableClob(I)|| p_Delimiter || ReturnValueClob;
              END LOOP;
              RETURN ReturnValueClob;
        END Branch;
    END Hierarchy;
    SHOW ERRORSAs you can see, I only changed the VARCHAR2 version. I'll leave changing the CLOB version as an exercise for you.
    When you call branch, pass a unique number for each column of output. If you don't explicitly give a number, it will default to 0.
    Here's your query modified to call it:
    SELECT  'A' || SUBSTR ( hierarchy.branch ( LEVEL
                                           , n2
                    , 2
                    )          AS path
    ,     hierarchy.branch ( LEVEL
                    , d
                    , '+'
                    , 12
                    )     AS sum_dist
    FROM    distances
    START WITH          n1 = 'A'
    CONNECT BY NOCYCLE      PRIOR n2     = n1
    ;For path, I called branch with only 3 arguments, so it's using vl (0) for internal storage for path.
    For sum_dist, I had to use a different integer. I couldn't decide if I should use 1 or 2, so I compromised and used 12. I could have used any integer, except 0.
    Output:
    PATH                           SUM_DIST
    A                              7
    A-C                            7+10
    A-C-D                          7+10+11
    A-C-D-E                        7+10+11+6
    A-C-F                          7+10+2
    A-C-F-E                        7+10+2+9
    A-D                            7+15
    A-D-E                          7+15+6
    A                              9
    A-D                            9+11
    A-D-E                          9+11+6
    A-F                            9+2
    A-F-E                          9+2+9
    A                              14
    A-E                            14+9
    or is there another way to solve this problem?, or even better, another way to solve the original problem (ORA-01489)Since you're calling a user-defined package, you might want to add other features to the package.
    For starters, in addition to a function that returns a string like '7+10+11', it might be handy to have a string that keeps those numbers internally, but returns the actual value 7 + 10 + 11 = 28.
    If you're using this for problems where you want to find the path with the least total d (or the greatest total d, for that matter, but for now let's say you're only interested in the minimum), you might want a function that keeps track of the minimum total d encountered so far for each node. Every time you find a different path to a node, the function could check to see if the total d is better than the previous best. If not, it could return a flag (sort of like CONNECT_BY_ISCYCLE) that tells you not to bother with that path any more.

  • ORA-01489

    How to solve this error?? Result of string concatination is too long. I'm firing a query which concats column values and displays them in a single column. Now for a table with above 300 columns in it i got the error. What should i do????

    Sorry the query is too large to post. But still i'm giving you the piece of code where the changes is required. Do you all think that converting the fields into CLOB will make it a success? Or I need to do any further changes to accept a large object.
    decode(a.CUSTOMER_SID,b.CUSTOMER_SID, null,'CUSTOMER_SID=('||a.CUSTOMER_SID||','||b.CUSTOMER_SID||')')
    ||''|| decode(a.GL_CLASS,b.GL_CLASS, null,'GL_CLASS=('||a.GL_CLASS||','||b.GL_CLASS||')')
    ||''||........ like other 300 columns.
    Do i need to do>>>>
    to_clob(decode(a.CUSTOMER_SID,b.CUSTOMER_SID, null,'CUSTOMER_SID=('||a.CUSTOMER_SID||','||b.CUSTOMER_SID||')'))
    ||''|| to_clob(decode(a.GL_CLASS,b.GL_CLASS, null,'GL_CLASS=('||a.GL_CLASS||','||b.GL_CLASS||')'))
    ||''||to_clob(......)........

  • Ring Item text string too long to display all - use ellipses ?

    The width of my Ring control is not wide enough to display all characters in the Item text string.  LabVIEW simply truncates the text with no indication that additional text is present.  Is there a way to display an ellipses in such cases ?  For example :
    "Ring text string that is too long"
    that is now shown as :
    "Ring text string that i"
    could be shown as :
    "Ring text st...too long"

    A couple of suggestions:
    1.) Use property nodes to determine which strings are too long, then concatenate the strings with ellipses.
    2.) Increase the height so the text wraps.
    "There is a God shaped vacuum in the heart of every man which cannot be filled by any created thing, but only by God, the Creator, made known through Jesus." - Blaise Pascal

  • Using clobs and ORA-01704: string literal too long

    Hi,
    I am attempting to add oracle support to an existing J2ee application. The issue I am facing is the use of CLOB datatypes and the 4k string literal limitation that Oracle has.
    I have dowloaded the 10.2.0.3 thin driver and am connected to a 9i release 2 database. When I execute a statement such as the following (say the table has one varchar2 field and two clob fields
    Insert into my_table VALUES ('hi','something','pretend this string is 5000 characters')
    I still receive the error
    java.sql.SQLException: ORA-01704: string literal too long
    I have read that the version 10 drivers were supposed to address this limitation. Is there something I am missing or must I change my home grown database layer to use bind variables or clob manipulation in a separate update/insert statement.? I am trying to avoid this situation since the database layer works fine for the situation of MSSQL and text fields which have no such limitation.
    Any advice you have here is greatly appreciated.
    Thanks,
    Joe

    Hi,
    I am attempting to add oracle support to an existing J2ee application. The issue I am facing is the use of CLOB datatypes and the 4k string literal limitation that Oracle has.
    I have dowloaded the 10.2.0.3 thin driver and am connected to a 9i release 2 database. When I execute a statement such as the following (say the table has one varchar2 field and two clob fields
    Insert into my_table VALUES ('hi','something','pretend this string is 5000 characters')
    I still receive the error
    java.sql.SQLException: ORA-01704: string literal too long
    I have read that the version 10 drivers were supposed to address this limitation. Is there something I am missing or must I change my home grown database layer to use bind variables or clob manipulation in a separate update/insert statement.? I am trying to avoid this situation since the database layer works fine for the situation of MSSQL and text fields which have no such limitation.
    Any advice you have here is greatly appreciated.
    Thanks,
    Joe

  • PL-SQL-ORA-01704 - String literal too long

    Hello guyz;
    I am trying to store a value of over 4000 character long in a CLOB column and I got the error message that says "PL-SQL-ORA-01704 - String literal too long".
    What can I do to overcome this challenge?
    Thanking you for your usual support.

    sb92075 wrote:
    Problem Exists Between Keyboard And Chair
    We can't say what you are doing wrong since we don't know specifically what you actually do.Okay let me put it down this way.
    I have an application using SQL Server as d backend engine & now, the user wants to migrate to Oracle. I now wrote a mini-program to create a schema/user in oracle with the schema/database (being used by the app) from SQL server. I verified the structure very well & every is just fine. Now, data migration (from SQL Server to Oracle).
    I was able to move most tables data successfully without issue until I attempted to load a table which has a column (in SQL defined as text with over 4000 (var)chars/CLOB in Oracle). On moving a particular row to oracle db (after few rows have already been INSERTed into this particular table x), I got that err msg.
    After battling with that for a while, I concluded to make d (DataMigrator) app take just d first 4000 string - only if the value in that field value length > 4000. This worked perfectly without issue but you know the implication - Data lost.
    Do I need to switch something on/off in Oracle that expands the CLOB default maximum field size? Because I foresee this happening as soon as the application (that would now sit on Oracle) is now in use.
    If you still don't understand this, I don't know how beta 2 explain this!
    Edited by: aweklin on Mar 17, 2013 8:25 AM
    Edited by: aweklin on Mar 17, 2013 8:25 AM
    Edited by: aweklin on Mar 17, 2013 8:27 AM
    Edited by: aweklin on Mar 17, 2013 8:27 AM

  • "ORA-01704: string literal too long" in Oracle 10g

    I would like to explain my problem with an example, let's create the following table:
    CREATE TABLE longtest
    (text LONG);
    I have to insert lots of data into this table and when I run this command:
    INSERT INTO LONGTEST VALUES ('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    ..................more than 4000 characters..................
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa');
    I get the following error:
    ORA-01704: string literal too long
    To workaround this, I used bind variables, like this:
    BEGIN
    EXECUTE IMMEDIATE 'INSERT INTO LONGTEST VALUES (:a) '
    using
    'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    ..............(repeat more than 32768 characters)..............
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa';
    COMMIT;
    END;
    This worked fine with Oracle 9.2.0.4 but when I do the same thing
    in Oracle 10.2.0.2 there is a 32768 characters limit.
    I am planning to upgrade the database but I need a workaround for
    this, anyone knows why Oracle behaves differently in 10g??

    So, I wonder if anyone can explain why the following code works fine in Oracle 9.2.0.4 but not in Oracle 10.2.0.2:
    CREATE TABLE longtest
    (text LONG);
    BEGIN
    EXECUTE IMMEDIATE 'INSERT INTO LONGTEST VALUES (:a) '
    using
    'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    ..............(repeat more than 32768 characters)..............
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa';
    COMMIT;
    END;
    Regards,
    Cassiano

  • ORA-01704: string literal too long (URGENT)

    Folks,
    I get error - ORA-01704: string literal too long,
    when trying to insert a value >4k into the SDIDOC column of the table below:
    CREATE TABLE "B1"."SDI_XML_TAB"
    ( "SDIID" VARCHAR2(60 BYTE) NOT NULL ENABLE,
    "SDIDOC" "SYS"."XMLTYPE" ,
    CONSTRAINT "SDI_XML_TAB_PK" PRIMARY KEY ("SDIID")
    USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
    STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "B1SYSTEM" ENABLE
    ) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
    STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "B1SYSTEM"
    XMLTYPE COLUMN "SDIDOC" STORE AS CLOB (
    TABLESPACE "B1SYSTEM" ENABLE STORAGE IN ROW CHUNK 16384 PCTVERSION 10
    NOCACHE LOGGING
    STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)) ;
    The SQL I used using OCI was:
    "INSERT INTO SDI_XML_TAB(SDIID,SDIDOC) VALUES('ABC','clobVal')"
    What am I doing wrong?
    P.S. I also used the following and it gives the same error:
    "INSERT INTO SDI_XML_TAB(SDIID,SDIDOC) VALUES('ABC',XMLType('clobVal'))"
    Thanks,
    Arthur
    Message was edited by:
    ArthurJohnson

    Check this cool-bi.com

  • Limitation for CLOB columns? - ORA-01704: string literal too long

    Hello!
    I'm trying to update a CLOB column with more than 35000 characteres, but I get "ORA-01704: string literal too long".
    The code:
    declare
    l_clob clob;
    begin
    update test set test = empty_clob()
    WHERE ID = 1
    returning test into l_clob;
    dbms_lob.write( l_clob, length('A...here 35000xA...A'), 1,'A...here 35000xA...A');
    end;
    Is there any limitation for CLOB columns?
    Thanks for help.
    Daniel

    user605489 wrote:
    32768 characteres :)Actually it's 1 character less than 32K...
    *32767*
    SQL> declare
      2    v_vc varchar2(32768);
      3  begin
      4    null;
      5  end;
      6  /
      v_vc varchar2(32768);
    ERROR at line 2:
    ORA-06550: line 2, column 17:
    PLS-00215: String length constraints must be in range (1 .. 32767)
    SQL>I guess it comes from a legacy thing where signed words (2 bytes) are/were used to represent a value. As the most significant bit of the word is used to represent the sign of the number the range goes from -32768 to 32767.

Maybe you are looking for