ORA-01489: result of concatenating string is too long

Similar Questions

• Get the ORA-01489 "result of concatenating string is too long."

  Hello world

  Im having problems with updating of a specific field. I got this error after I run my Update statement.

  * Cause: Result of concatenation of string exceeds the maximum size.

  * Action: Make sure that the result is less than the maximum size.

  Here is my script:

  declare
  cursor material is
      SELECT tt.column2,
             m.name, 
             m.MATERIAL_ID,
             tt.column3,
             tt.column4,
             tt.column5,
             tt.column6,
             tt.column7,
             tt.column8
      FROM material m, tmp_text tt
      WHERE m.NAME like tt.column2 || '%'
      AND tt.column9 = 'SI';
     
              begin
  
    for u in material loop
     
      update material
      set fields_xml =  '<?xml version="1.0" encoding="UTF-8"?>
                          <fields>
                            <field type="text" name="Size EU" maxlength="200"/>
                           <field type="text" name="Size UK" maxlength="200"/> 
                           <field type="text" name="Weight per size" maxlength="200"/>
                           <field type="text" name="Shaft height" maxlength="200"/>  
                           <field type="textarea" name="Product Description Norwegian" maxlength="2000">' || u.column8 || '</field>
                           <field type="textarea" name="Product Description Swedish" maxlength="2000">' || u.column7 || '</field>
                           <field type="textarea" name="Product Description Danish" maxlength="2000">' || u.column4 || '</field>
                           <field type="textarea" name="Product Description Finnish" maxlength="2000">' || u.column5 || '</field>
                           <field type="textarea" name="Product Description German" maxlength="2000">' || u.column6 || '</field>
                           <field type="textarea" name="Product Description English" maxlength="2000">' || u.column3 || '</field>
                           <field type="text" name="Additional Information" maxlength="200"/>
  
  
                           
                          </fields>'
      where material_id = u.material_id;
  
  
  
       end loop;
  
  end;
  
  
  
  
  
  
  
  
  
  
    
  

  That the script is that it will update the 'FIELD_XML' (CLOB) field in the table "material". I know that it exceeds the maximum size. Is there another way to do this?

  I would like to know your opinion... Thank you guys.

  Hello

  You can try with CLOB variable declaration and concatenate the value you want in it.

  For example:

  declare
  cursor material is
      SELECT tt.column2,
             m.name,
             m.MATERIAL_ID,
             tt.column3,
             tt.column4,
             tt.column5,
             tt.column6,
             tt.column7,
             tt.column8
      FROM material m, tmp_text tt
      WHERE m.NAME like tt.column2 || '%'
      AND tt.column9 = 'SI';
  
      v_clob CLOB;  
  
              begin  
  
    for u in material loop
      v_clob := '
                          
                            
                           
                           
                           
                           ';
      v_clob := v_clob || u.column8 || ' ';
      v_clob := v_clob || '' || u.column7 || ' ';
      v_clob := v_clob || ''  || u.column4 || ' ';
      v_clob := v_clob || '' || u.column5 || ' ';
      v_clob := v_clob || ''  || u.column6 || ' ';
      v_clob := v_clob || '' || u.column3 || ' ';
      v_clob := v_clob || ''
      update material
      set fields_xml =  v_clob
      where material_id = u.material_id;
       end loop;
  end;
  

  Cheerz,

  Stako

• error "result of concatenating string is too long" when I try to run the following code. Help me!

  When I try to perform the following PROCEDURE, he throws me an error:

  Error from line: 2 in command.

  BEGIN

  FACT_UPDATE;

  END;

  Error report-

  ORA-01489: result of concatenating string is too long

  ORA-06512: at "AFLOBIDW. FACT_UPDATE', line 22

  ORA-06512: at line 2

  01489 00000 - "result of concatenating string is too long."

  * Cause: Result of concatenation of string exceeds the maximum size.

  * Action: Make sure that the result is less than the maximum size.

  ---------------------------------------------------------------------------

  I can't change the logic of the code since I'm trying to do Informatica at the back done and compare performance between Informatica and Oracle DB. Is there another solution for errors? I add only the SQL query that is part of the PROCEDURE for easy viewing. Please help me. Thank you!

  SELECT "UPDATE XXAFL_MON_FACTS_F SET TASK_WID ='"

  || NVL (TO_CHAR (TASK_WID), 'NULL')

  |', EXECUTION_PLAN_WID ='

  || NVL (TO_CHAR (EXECUTION_PLAN_WID), 'NULL')

  || ', DETAILS_WID ='

  || NVL (TO_CHAR (DETAILS_WID), 'NULL')

  |', SOURCE_WID ='

  || NVL (TO_CHAR (SOURCE_WID), 'NULL')

  |', TARGET_WID = '

  || NVL (TO_CHAR (TARGET_WID), 'NULL')

  || ', RUN_STATUS_WID ='

  || NVL (TO_CHAR (RUN_STATUS_WID), 'NULL')

  |', SEQ_NUM ='

  || NVL (TO_CHAR (SEQ_NUM), 'NULL')

  |', NAME = "'

  || NVL (TO_CHAR (NAME), 'NULL')

  || ' ', NO_POSITION = "'

  || NVL (TO_CHAR (INSTANCE_NUM), 'NULL')

  ||'' ', INSTANCE_NAME = "'

  || NVL (TO_CHAR (INSTANCE_NAME), 'NULL')

  || ' ', TYPE_CD = "'

  || NVL (TO_CHAR (TYPE_CD), 'NULL')

  ||'' ', STATUS_CD = "'

  || NVL (TO_CHAR (STATUS_CD), 'NULL')

  ||'' ', START_TS ='

  || DECODE (START_TS, ",' to_date(''e))

  || To_char (START_TS, "mm/dd/yyyy hh)

  ||'' ((', "dd/mm/yyyy hh")')

  || ', END_TS ='

  || DECODE (END_TS, ",' to_date(''e))

  || To_char (END_TS, "mm/dd/yyyy hh)

  ||'' ((', "dd/mm/yyyy hh")')

  |', DURATION = '

  || NVL (TO_CHAR (DURATION), 'NULL')

  |', STATUS_DESC = "'

  || NVL (TO_CHAR (STATUS_DESC), 'NULL')

  || ' ', DBCONN_NAME = "'

  || NVL (TO_CHAR (DBCONN_NAME), 'NULL')

  ||'' ', SUCESS_ROWS ='

  || NVL (TO_CHAR (SUCESS_ROWS), 'NULL')

  || ', FAILED_ROWS ='

  || NVL (TO_CHAR (FAILED_ROWS), 'NULL')

  |', ERROR_CODE = '

  || NVL (TO_CHAR (ERROR_CODE), 'NULL')

  |', NUM_RETRIES ='

  || NVL (TO_CHAR (NUM_RETRIES), 'NULL')

  || ', READ_THRUPUT ='

  || NVL (TO_CHAR (READ_THRUPUT), 'NULL')

  |', LAST_UPD = '

  || DECODE (LAST_UPD, ",' to_date(''e))

  || To_char (LAST_UPD, "mm/dd/yyyy hh)

  ||'' ((', "dd/mm/yyyy hh")')

  |', RUN_STEP_WID = "'

  || NVL (TO_CHAR (RUN_STEP_WID), 'NULL')

  || ' ', W_INSERT_DT = '

  || DECODE (W_INSERT_DT, ",' to_date(''e))

  || To_char (W_INSERT_DT, "mm/dd/yyyy hh)

  ||'' ((', "dd/mm/yyyy hh")')

  |', W_UPDATE_DT = '

  || DECODE (W_UPDATE_DT, ",' to_date(''e))

  || To_char (W_UPDATE_DT, "mm/dd/yyyy hh)

  ||'' ((', "dd/mm/yyyy hh")')

  || ', START_DATE_WID ='

  || NVL (TO_CHAR (START_DATE_WID), 'NULL')

  |', END_DATE_WID = '

  || NVL (TO_CHAR (END_DATE_WID), 'NULL')

  |', START_TIME ='

  || NVL (TO_CHAR (START_TIME), 'NULL')

  |', END_TIME ='

  || NVL (TO_CHAR (END_TIME), 'NULL')

  ||' WHERE INTEGRATION_ID = "'

  || INTEGRATION_ID

  ||''';' AS Column

  OF XXAFL_MON_FACTS_F;

  Hello

  ORA-01489 is one of these error messages that really means what he says. The error message you posted pretty much sums up the situation.

  What version of Oracle are you using?  (You must still include this whenever you have a question.  See the FAQ forum: Re: 2. How can I ask a question on the forums? )

  From 12.1 of the Oracle, there is an option to allow VARCHAR2s in SQL to be as big as 32767octets.  (The default is 4000).

  Otherwise, if you can't change the code, either do not run. or ensure that the concerned channels are quite short so the error does not occur.

• LISTAGG function: "result of concatenating string is too long."

  Hello
  
  I use Oracle SQL developer 3.0.04 version. I tried using the LISTAGG function to group the data.
  

  CREATE TABLE FINAL_LOG AS
  SELECT SESSION_DT, C_IP, CS_USER_AGENT,
  listagg(WEB_LINK, ' ')
       WITHIN GROUP(ORDER BY C_IP, CS_USER_AGENT) "WEB_LINKS"
       FROM webviews
       GROUP BY C_IP, CS_USER_AGENT, SESSION_DT
       ORDER BY SESSION_DT

  However, I get the error message,
  
  SQL error: ORA-01489: result of concatenating string is too long
  
  Is it possible to go around it, or are there other alternatives?

  Tim Hall has a page on the various techniques of aggregation of chain that guides you through an example of creating and using a user-defined aggregate.

  On AskTom referenced by Tim page, there is an implementation of an aggregation function of string that returns a CLOB that you can use.

  If you want to understand what makes the user-defined aggregate function, it may look a bit complex, especially if you have never looked at object types in PL/SQL. You don't need to understand all the details of the implementation if you use just the code, however, you can simply create the function and use it as you would with any other aggregate function.

  Justin

• "ORA - 01489:result of concatenation of string is too long" (the chain is small)

  Hello
  
  I am using the listagg as follows function but get ORA-01489: result of concatenating string is too long.
  
  SELECT LOCATIONID, LISTAGG (TO_CHAR (WHICH |)) ',' || (POSITIONY), ',') ADR WITHIN GROUP (ORDER BY SEQUENCENUMBER)
  OF POSITIONPOINTS
  GROUP BY LOCATIONID
  AFTER HAVING COUNT (SEQUENCENUMBER) = 20;
  
  When I try to run this in Oracle Sql Developer, he shows the lines first in 1550, then reports the error ORA-01489. In total 2612 lines must be returned, all values in ADR having a length of approximately 440 characters. An example of one of the lines that developer Sql is back is:
  
  22372682 410434.801,551142.885,410434.784,551142.875,410439.801,551141.922,410439.991,551141.795,410439.293,551138.303,410438.531,551137.668,410429.768,551134.302,410427.228,551133.159,410426.212,551132.143,410425.196,551129.667,410421.957,551114.3,410414.972,551081.28,410413.639,551076.136,410412.94,551073.66,410412.94,551072.326,410413.639,551071.628,410415.798,551070.612,410416.369,551069.469,410416.877,551068.834,410433.23,551061.795
  
  There are a few LocationIDs in table PositionPoints that have more than 20 entries (max is 254), and for these lines, I want the concatenated string more than the maximum of 4000 characters. However, where count (sequencenumber) = 20, the length of the concatenated string would be less than 500. Oracle running concatenations even for places that I've excluded with my HAVING clause and an error on these?
  
  I tried to run the query at the time Oracle Sql Developer and SQL Plus.
  
  Would be grateful if someone could shed some light on this issue.
  
  Thank you

  Ronnie m says:
  Oracle running concatenations even for places that I've excluded with my HAVING clause and an error on these?

  Yes, that's the explanation.
  HAVING is not WHERE it is applied after the grouping is performed.

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

  Hello
  
  I use the Oracle 11.2.0 database.
  
  When querying my database with a common table expression that concatenates strings VARCHAR2, I get an error ORA-01489 even if I suspect that I am concatenating more 4000 characters.
  
  To be more precise, I have a table entity which basically stores the XML elements, including their parent element and their position of brother among his brothers and sisters. 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 items to be concatenated with their ancestors elements to a structure as follows:
  
  "(/ 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 fair values in the name column of the table of the entity)
  
  To do this, I use a common table expression that concatenates the values of name and sibling_pos as shown below:
  
  WITH entity_cte (lvl, id, path) as)
  SELECT 1 AS lvl, id, ' / '. name | ' (0' | sibling_pos |) ')' IN the path
  OF the entity
  WHERE parent IS NULL
  UNION () ALL THE
  SELECT lvl + 1 lvl, e.id, entity_cte.path | '/' || e.Name | ' (': cast (e.sibling_pos AS VARCHAR2 (2)) |) ')' IN the path
  Of entity_cte, e entity
  WHERE entity_cte.id = e.parent
  )
  )
  SELECT lvl, id, path
  Of e entity_cte
  ;
  
  After the insertion of certain values, I get the error ORA-01489, the result of concatenating string is too long. The maximum is called as 4,000 characters for VARCHAR2 in the oracle documentation and various Web sites. Of course, it is clear to me just by using the common table like that expression, I could run in such an error. However, because of the structure of XML documents, I doubted that channels resulting would be since a long time more than 4000 characters.
  
  So I reorganized my query to count the characters to concatenate instead of actually concatenate. The query is listed below, that the changes are marked in "BOLD":
  
  WITH entity_cte (lvl, id, path) as)
  SELECT 1 lvl, id, length ('/ ' | name |)  ' (0' | sibling_pos |) ') IN the path
  OF the entity
  WHERE parent IS NULL
  UNION () ALL THE
  SELECT lvl 1 lvl, e.id, AS entity_cte.path + length ('/ ' | e.name |) ' (': cast (e.sibling_pos AS VARCHAR2 (2)) |) ') IN the path
  Of entity_cte, e entity
  WHERE entity_cte.id = e.parent
  )
  )
  SELECT lvl, id, path
  Of e entity_cte
  Way to ORDER BY DESC
  ;
  
  The result of the query gives me a maximum length of 319 characters.
  
  To be sure, I also checked the maximum level (indicated by the column named lvl in the common table expression), which means that the maximum number of items in my way (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 to 18 levels would be 1890.
  
  So, now I wonder is the ORA-01489 may have triggered another reason? Or is there something else I'm missing?
  Any help would be appreciated. Other suggestions to track down the error are more than welcome. Thanks in advance.

  I found by trial and error that launch the query anchor seems to work, but I don't know why, then you can try this.

  with entity_cte (lvl, id, path)
  as
      (
      select
          1 lvl,
          id,
          cast('/' || name || '(0' || sibling_pos || ')' as varchar2(4000))  path
      from
          entity
      where
          parent is null
      union all
      select
          lvl + 1 lvl,
          e.id,
          entity_cte.path || '/' || e.name || '(' || cast(e.sibling_pos as varchar2(2)) || ')' path
      from
          entity_cte,
          entity e
      where
          entity_cte.id = e.parent
      )
  select lvl, id, path
  from entity_cte e
  ;
  

  Not tested since no table definitions or examples of data provided.

• Literal string is too long and too small string buffer

  Hello

  Can someone please explain what the difference is between these two errors.

  The maximum size of the character in SQL is 4000 and PL/SQL its 32 k. So if a string literal exceeds this limit "string literal too long" error message is triggered by oracle.

  Here is an example

  SQL> select 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    2  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    3  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    4  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    5  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    6  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    7  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    8  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    9  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   10  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   11  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   12  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   13  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   14  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   15  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   16  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   17  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   18  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   19  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   20  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   21  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   22  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   23  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   24  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   25  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   26  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   27  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   28  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   29  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   30  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   31  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' str
   32    from dual;
  select 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
         *
  ERROR at line 1:
  ORA-01704: string literal too long
  

  Now, when you try to set a string variable with a value greater than the defined size, you get "too small character string buffer.

  Here is an example

  SQL> declare
    2    var varchar2(1);
    3  begin
    4    var := 'aa';
    5  end;
    6  /
  declare
  *
  ERROR at line 1:
  ORA-06502: PL/SQL: numeric or value error: character string buffer too small
  ORA-06512: at line 4
  

  Oracle error message there two of each, one for SQL and one for PL/SQL.

  ORA-19011: character string buffer too small

  Cause : the result of the chain asked is too big to go back

  Action : get the result like a lob instead

  ORA-01704: string literal too long

  Cause : the string literal is longer than 4000 characters.

  Action : use a string literal of more than 4,000 characters. Longer values can only be entered using bind variables.

  PLS-01905: character string buffer too small

  Cause : an error occurred while moving a string from a source to a destination. This error occurs if, for example, an attempt is made to move an a string of 10 characters into a buffer of 1 character. The cause of this error may not always be obvious. For example, the following will cause this error: a varchar2 (1); b the number; b: = 10; a: = b; An error occurs because an implicit conversion causes the number 10 to become the string '10', which does not fit in memory buffer of characters of 1 assigned to the variable.

  Action : first, look for the character string assignment statements where the size of the buffer is incompatible. If there is none found, then consider the case of an implicit conversion shown in the example above.

  PLS-00172: string literal too long

  Cause : the string literal is longer than 32767octets.

  Action : use a string literal of at most 32767octets.

• CLob update fails with PLS-00172: string literal too long

  I have a clob column that needs updating with a message about message_id
  
  Description of the table
  
  SQL > desc cl_message1
  Name Null? Type
  ----------------------------------------- -------- ----------------------------
  MSG_ID(2) NOT NULL NUMBER (10)
  DATA NOT NULL CLOB
  
  UPDATE statement:
  CLOB variable data1;
  Start
  : data1: ='TESTHDR ^ add ^ 200812310374 ^ 15:53:22.0 2012-08-19 ^.
  TESTHDR ^ add ^ 200812310374 ^ 5652 ^ C0000029 ^ 15:46:49.0 2012-08-19 ^.
  TESTDWN ^ ADD ^ 200812310374 ^ 5652 ^ G ^ 03 ^ 00000999990000722444 ^.
  .....
  ... ----------------------------------------------------------------------------------------- 2376 lines of text-------------------------
  TESTDWN ^ ADD ^ 200812310374 ^ 5674 ^ G ^ 10 ^ 00000999990000743289 ^.
  TESTEND ^ 5674 ^';
  UPDATE cl_message1
  SET DATA =: data1
  WHERE
  msg_id(2) = '989';
  END;
  /
  
  When I run this statement it fails with
  
  
  SQL > @test_clob_insert.sql
  : data1: ='WAVEHDR ^ add ^ 200812310374 ^ 15:53:22.0 2012-08-19 ^.
  *
  ERROR on line 2:
  ORA-06550: line 2, column 10:
  PLS-00172: string literal too long
  
  According to my understanding of a bind variable can store a maximum of clob. Not sure why it is throwing this error. Help, please
  
  Concerning
  
  This column is stored in_row.
  
  
  SQL > r
  1 * select table_name, column_name, owner, in_row from dba_lobs where table_name = 'CL_MESSAGE1 '.
  
  OWNER, TABLE_NAME COLUMN_NAME IN2
  ------------------------------ ------------------------------ ---------------------------------------- ---
  VEERA CL_MESSAGE1 DATA YES
  
  Published by: 953621 on August 19, 2012 22:34
  
  Published by: 953621 on August 19, 2012 23:44

  953621 wrote:
  According to my understanding of a bind variable can store a maximum of clob. Not sure why it is throwing this error. Help, please

  Yes, if the binding variable is declared as a clob, so it can store the maximum size of the CLOB, but this isn't your problem.
  Your problem is that you set the clob data using a string literal that is a single quoted string. There is a limit to the size of the string literals, so you will have to accumulate the clob in adding a whole lot string literals instead.

• SYS. DBMS_SQL. Version of overload of PARSE CLOB error PLS-00172: string literal too long.

  I have This Oracle 12c Procedure

CREATE OR REPLACE PROCEDURE LOGINCHECK(stmt IN CLOB)
AS
  C INTEGER;
  N INTEGER;
  RC SYS_REFCURSOR;
BEGIN
  C := SYS.DBMS_SQL.OPEN_CURSOR;
  SYS.DBMS_SQL.PARSE(C,stmt,DBMS_SQL.native);
  N := SYS.DBMS_SQL.EXECUTE(C);
  SYS.DBMS_SQL.GET_NEXT_RESULT(C,RC);
  SYS.DBMS_SQL.RETURN_RESULT(RC);
EXCEPTION
WHEN NO_DATA_FOUND THEN
   NULL;
when OTHERS then
  RAISE;
END LOGINCHECK;

  
  

  for example, to create an oracle with a xml or clob type IN FastInventory procedure and pass xml from this link https://drive.google.com/file/d/0BwAVQqYmX0-zQ1d1VnNmZndfcVE/view?usp=sharing
  

  
  

  The of the stmt parameter is approximately 50000 characters.
  

  
  

  DBMS_SQL. ANALYSIS gives error PLS-00172: string literal too long.

  
  

  I'm passing stmt My .net code as parameter . OracleDbType.Clob then why this error occurring.

  
  

  I use Oracle 12 c database. Visual Studio 2012, .net Framework 4;
  

  OK now I have a response team of oracle.net where it says on tweeter

  @OracleDOTNET team .NET oracle

  Seems to be a bug specific to PL/SQL, because the error occurs on the DBMS_SQL. ANALYZE the call

  Thank you all who have helped and at least tried to solve this problem.

• Application of THEME - MAPVIEWER - 05517 JDBC string is too long for Oracle cards-

  Hello
  
  If I need a fairly complex query to add the dynamic JDBC theme I get this error:
  
  [MAPVIEWER-05517] Ask the string is too long for no AJAX of Oracle remote access cards.
  
  -Why? I use Oracle Maps API JS isn't remote AJAX or not?
  -What is the limit of a definition of the JDBC theme?
  
  Kind regards
  Brano

  Put this code after creating object mapviewer.

  MVMapView.enableXMLHTTP (true);

• UserAgent string is too long

  Hi everyone, I am running a problem on some browsers in our society where the UserAgent string is causing our Sentinel page code to die. The code we have is:
  
  ...
  If wwv_flow.get_browser_version = "PNSC" then
  ...
  
  If the UserAgent string is longer than 256 characters, we get:
  
  ORA-06502: PL/SQL: digital or value error: character string buffer too small
  
  Track of the back ends here:
  
  ORA-06512: at "APEX_030200.WWV_FLOW", line 13977
  
  Is this a known bug, or is there a workaround?
  
  Thanks in advance.

  Hello:

  It's a bug where the wwv_flow.get_browser_version API expects the string USER_AGENT is no more than 256 characters :)
  Take a look at the OWA_UTIL. GET_CGI_ENV API. You can use this API in your code to get the USER_AGENT string your own in a personalized way.

  SELECT owa_util.get_cgi_env ('HTTP_USER_AGENT') FROM DUAL;

  CITY

• Bug: Find/replace does not work if the statement contains the string is too long

  Hello

  in my sequence, I press Ctrl + F to open the Find dialog box and enter a string. All the checkboxes are checked 'Elements for search' and ' limit the search to "is not enabled.

  Now comes the finding it is only announcing the discovery in the main sequence.

  Other places in a sous-suite that are part of a labview vi action setting is not in the list. Also if I open the sequence and I'm looking at this place.

  If I create a comment in the subsequence containing the searchstring, then it is.

  When I open the properties of the action of labview and open the parameter that contains the string and click on check for errors, and then close all and supplementary search then the value lies.

  Is it possible that the variable is too long setting? It's about 200 characters and one thing very nested SationGlobals and the table and the TestSockets. Search string Dees is finally an arrayindex in this grand statement.

  It seems that this is the problem.

  Is this a known bug?

  Solved.

  There was an empty character at the end of the search string...

• log in - help sql: error ORA-01489: string concatena result

  Here's a sql query and I am cooking a decoding, but since there are several columns invloved when I try to run it I get the following error:
  ORA-01489: result of concatenating string is too long
  
  Any kind of help is appreciated, I need to get it going or I'm dead :(
  
  Concerning
  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, prev rownum-1
  from (select rownum rn
  Double connect 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
  the double)), (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' | (',' double all_cols) b) c
  Start by curr = 1
  Connect prior curr = prev
  length (sys_connect_by_path(c.decode_prep,'-')) desc order
  
  ---------------------------------------------------------------------------------------------
  
  same as above sql only the difference is here I'm pulling the first record in the result set that top query returns:
  
  Select ltrim (replace(decode_prep,'-','||'),'| ') decode_prep
  of (sys_connect_by_path(c.decode_prep,'-') select 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, prev rownum-1
  from (select rownum rn
  Double connect 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
  the double)), (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' | (',' double all_cols) b) c
  Start by curr = 1
  Connect prior curr = prev
  length (sys_connect_by_path(c.decode_prep,'-')) desc order)
  where rownum = 1
  
  Published by: Mac_Freak_Rahul on November 28, 2012 01:31: in the first sql ')'
  removed after desc in the last line so now this query begin and will throw an error.

  Mac_Freak_Rahul wrote:
  @Blushadow:

  (1) first of all, I'm sorry for not posting my question according to the rules of the forum, next time I'll take care of that.
  (2) Secondly, thanks for the solution, I have no exp with clob, but I can take a deeper look later.
  (3) I just want to know if there are any other wayout, you mean the second concatenation of 4000 bytes sys_connect_by_path exhausts it might return this error?

  SYS_CONNECT_BY_PATH returns a VARCHAR2 data type. In SQL VARCHAR2 data type is limited to 4000 bytes, then Yes, you will get an error if the data that you generate is greater than 4000 bytes (and I say bytes rather than characters, because if your database uses a multibyte multi character set could be as little as 1000 characters)

  I'm right now stable for a table who got 62 columns... I have tables that have 200 close passes: (, great, if you can throw some light on this, if your the best way and the only one to achieve?)

  If you really need to concatenate strings together which exceeds 4000 bytes, then Yes you must use CLOB to store data. Oracle does not provide a native way to aggregate together in a CLOB datatype string, so why you need to write your own function.

  PS: just a quick overview of my value, it will be by comparing schema1.table (s) with shema2.table (s) where table_name must be the same...

  So why are you information concatenation together to achieve this goal?

• ORA-01489 sys_connect_by_path and previous solution does not

  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."
  AMT for Linux: Version 11.2.0.1.0 - Production
  NLSRTL Version 11.2.0.1.0 - Production
  
  I need to get directions in a card and the associated amount long distances to another.
  

  map
  --     9
    F ----------E
    | \         |
    |  \2       |6
    |   \   11  |
  14|   C-------D
    |  / \10   /
    | /9  \   /15
    |/     \ /
    A-------B
       7

  I have a query that gets the roads properly.
  

  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+9

  The problem is when there is a lot of knots, I get an ORA-01489: result of concatenating string is too long.
  
  I followed this link.
  
  SYS_CONNECT_BY_PATH & to_CLOB
  
  I built the package specified but apparently is combining elements.
  
  If it is called only once.

  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-F

  But 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+9

  As you can see, is to combine the node elements (A-10-11-E) - node distance - distance-
  
  Do I have to create separate functions in the package, one per column?, or is there another way to solve this problem?, or better yet, another way to solve the original problem (ORA-01489)
  
  Thank you very much.
  
  Kind regards.
  
  Package (by Solomon Yakobson) code:
  

  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;
  /

  Published by: sKr on 08-mar-2012 17:29
  Added package code

  Hello

  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."
  AMT for Linux: Version 11.2.0.1.0 - Production
  NLSRTL Version 11.2.0.1.0 - Production

  I need to get directions in a card and the associated amount long distances 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 'Useful' or 'Correct '. You get 10 points for sure.

  Do I have to create separate functions in the package, one per column.

  You need to separate the functions. A user-defined function should be enough, just like a built-in version of SYS_CONNECT_BY_PATH is sufficient. All that should be stored in their own country, he knows that he needs to keep a separate copy for each argument to which you call it with. The problem with the package, which had been initially posted, is that there is only a single BranchTableVarchar2 of internal variables. Instead of a variable, an array of similar variables and add an optional argument to the funtion branch to tell him which item in this table 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 ERRORS
  

  As you can see, I only changed the version of VARCHAR2. Let you change the CLOB as an exercise for you.

  When you call branch, pass a unique number for each output column. If you do not explicitly give a default number is 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
  ;
  

  Path, I called the branch with only 3 arguments, so that it uses vl (0) for internal storage for the 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 better yet, another way to solve the original problem (ORA-01489)

  Given that you call a user-defined set, 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 useful to have a string that maintains these numbers internally, but returns the value 7 + 10 + 11 = 28.
  If you use this for problems when you want to find the less total path (or the highest total d, for that of importance, but for now, let's say you are only interested in the minimum), you might want a function that keeps track of the minimum total d met so far for each node. Whenever you find a different path to a node, the function can check if the total d is better than the previous best. If this isn't the case, it could return an indicator (kind of similar CONNECT_BY_ISCYCLE) which indicates not bore you with this path.

• Get ORA-01489: with tabular

  Hello
  
  I have a tabular presentation that has a couple of apex_item.select_list_from_lov in the source query, for example
  
  SELECT Apex_item.hidden (1
  NULL
  )
  || apex_item.select_list_from_lov (4
  NULL
  , "LOV_POLICY".
  , "style =" width: 170px "'"
  || ')"'
  'NO '.
  NULL
  NULL
  , "f04_".
  || LPAD (9900
  + LEVEL
  4
  , '0'
  )
  NULL
  )
  || apex_item. Hidden (3
  NULL
  ) policy_name
  .....
  
  I now get an ORA-01489: result of concatenating string is too long error. It was working fine but the LOV which depends on one of the points went to a hundred documents, or so I'm half guess that the apex_item function creates a static string more than 4,000 characters, and thus the error.
  
  This has large implications for our application as long as there are several tabular forms that display data in this way (I assume that apex_item.select_list_from_query is no different) and it is likely that these selection lists will grow over time.
  
  Someone has encountered this problem themselves and found a solution? We have an Ajax solution but this will involve rewritten considerable and we have little time.
  
  Any suggestions greatly appreciated...

  Hello

  Do something like the following:

  1. create a LOV to SELECT NULL, NULL Ruy FROM DUAL and use this instead LOV_POLICY
  2. on your APEX_ITEM, add in the parameter which allows additional values
  3. under your existing area, create a new PL/SQL area that generates the actual values using something like:

  DECLARE
   vSEP VARCHAR2(1);
  BEGIN
   vSEP := '';
   htp.p('<script type="text/javascript">');
   htp.p('var sMaster = new Array(');
   FOR c IN (SELECT DNAME d, DEPTNO r FROM DEPT ORDER BY UPPER(DNAME))
   LOOP
    htp.p(vSEP || 'new Array (' || c.r|| ',"' || c.d|| '")');
    vSEP := ',';
   END LOOP;
   htp.p(')');
   htp.p('</script>');
  END;
  

  4. create another region below which set it on have No model and the source of the value:

  <script type="text/javascript">
  function updateList(sChild)
  {
   var o;
   var sChildValue = sChild.value;
   sChild.options.length = 0;
   o = new Option('-Select-', '');
   sChild.options.add(o);
   var k;
   for (k = 0; k < sMaster.length; k++)
   {
    o = new Option(sMaster[k][1], sMaster[k][0]);
    sChild.options.add(o);
   }
   sChild.value = sChildValue;
   if (sChild.selectedIndex == -1)
   {
    sChild.selectedIndex = 0;
   }
  }
  function updateLists()
  {
   var lists = document.getElementsByName("f04");
   var k;
   var x;
   if (lists)
   {
    for (k = 0; k < lists.length; k++)
    {
     updateList(lists[k]);
    }
   }
  }
  updateLists();
  </script>
  

  Now, when the page loads, each selection list will show a null value and the actual value. In this report, will be generated a javascript array that contains the appropriate values for the lists. Following that will be the JavaScript that traverses the playlists selection and fills them with the content of the table.

  The benefits of doing it this way are double - you work around issues with lengths of chain and the page will actually load a lot faster.