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

Tags: Database

Similar Questions

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.

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

ORA-01489: result of concatenating string is too long

Hola a todos, Necesito ayuda, estoy creando UN a plano cual tiene el archivo a linea of 11500 characters largo, pero al building the question me envia el error (ORA-01489) descrito, alguien sabe como avoid than aparezca este error, the idea are what run script desde este an archivo .bat o .sh
the request are the following
set pagesize 0
set linesize 11508
Go head
coil prueba_comex.txt;
Select rpad (nvl (A.SEGMENT1,' '), 100).
RPAD(A.ORGANIZATION_ID,100) |
RPAD (' ', 2) |
RPAD (' ', 2) |
RPAD (' ', 18).
RPAD (' ', 47).
RPAD (nvl (A.PRIMARY_UOM_CODE,' '), 4) |
RPAD (' ', 10).
RPAD ('99999999', 8).
RPAD (' ', 8).
RPAD (' ', 8).
RPAD ('0', 47).
RPAD ('0', 47).
RPAD (' ', 30).
RPAD (' ', 14).
RPAD (' ', 1) |
RPAD (' ', 1) |
RPAD (' ', 47).
RPAD (' ', 18).
RPAD (' ', 18).
RPAD (' ', 1) |
RPAD (' ', 1) |
RPAD (' ', 1) |
RPAD (' ', 47).
RPAD (' ', 47).
RPAD (' ', 47).
RPAD (' ', 47).
RPAD (' ', 47).
RPAD (nvl (A.DESCRIPTION,' '), 250).
RPAD (' ', 14).
RPAD (' ', 1) |
RPAD (NVL (A.WEIGHT_UOM_CODE, 'KG'), 4) |
RPAD ('KG', 4) |
RPAD (' ', 4) |
RPAD (' ', 4) |
RPAD (' ', 47).
RPAD (' ', 47).
RPAD (' ', 20).
RPAD (' ', 47).
RPAD (' ', 4) |
RPAD (' ', 1) |
RPAD (' ', 200).
RPAD (' ', 1) |
RPAD (' ', 1) |
RPAD ('P', 20).
RPAD('N',1) |
RPAD (' ', 1) |
RPAD (' ', 80).
RPAD (' ', 1) |
RPAD (' ', 1) |
RPAD (' ', 1) |
RPAD (' ', 1) |
RPAD (' ', 1) |
RPAD (' ', 4) |
RPAD (' ', 240).
RPAD (' ', 240).
RPAD (' ', 240).
RPAD (NVL (B.LONG_DESCRIPTION, A.Description), 4000)
tables...

If you run SQL * Plus in your scripts, then you need to set:

long value 32000 longc 200

"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.

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.

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.

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

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

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

Function - return multiple values in a concatenated string
Hello

Is it possible for a function return a concatenated string (combining more than one number). I'm trying to return the purchase by the introduction and invoice_id number and code order number, but an invoice_id can have several PO with the same code number. I want to concatenate the PO numbers with commas, for example

10124, 10090, 10987

At the present time, the function returns NULL for those cases that have more than one purchase order number.

Thank you
```
func_get_po(i.invoice_id, cc.code_combination_id) "PO No",
func_get_po_requester(i.invoice_id, cc.code_combination_id, func_get_po(i.invoice_id, cc.code_combination_id)) "PO Requester",
```
Of course, this can be done without any problem.
If it returns NULL, then you must debug function and check the operating logic. I know that it will take a little of your time, but not problems with the logic of syntax and concatenation.

CFC - URi too long during the passage of text string to CFC
I have a page that allows the user to save a large block of text which is held in a < div > tag to the database without reloading the page through cfajaxproxy and a cfc.

When you click on 'save' a javascript function draws text of the div block and stores it in a javascript string, which is then passed into a cfc using cfajaxproxy as a parameter to the javascript function. (ie. functionName (theTextBlockString);). It works fine except if the text contained in the javascript string var gets too long and causes a URi too long message.

Display of the request in firebug, that I see the cfc is called via a GET request, which causes all my input parameters that I placed in the service to be placed in a GET url string, so of course when it is a long block of text, only the URL query string is too long, and I get the message too long URI of the CFC.

What I'm trying to understand, is how hell I can pass a large text string in the EFA without encountering this problem. Is there an alternative application method so that I can't use GET?

Thank you in advance!

Dave
I found the setHTTPMethod parameter used during initialization of a cfc to cfajaxproxy - you can change it to a POSITION which obviously solves the problem. Adobe, mark POST by default as AJaxCFC, CFAjax, etc.! Maybe theres some reason to have default GET, who knows...

Literal string too long for the CLOB
Hello
My version of the database is:
Oracle Database 11 g Enterprise Edition Release 11.2.0.1.0 - 64 bit 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

When I run this piece of code, I get an error.
DECLARE
insCtx DBMS_XMLStore.ctxType;
lines NUMBER;
xmlDoc CLOB: = 'xml string is about 4600 long lines in TOAD...';
BEGIN
insCtx: = DBMS_XMLStore.newContext ("xmlTempTbl"); -get the context
lines: = DBMS_XMLStore.insertXML (insCtx, xmlDoc); -Insert the doc
DBMS_XMLStore.closeContext (insCtx); -close the handle
END;

ERROR:
ORA-06550: line 4, column 19:
PLS-00172: string literal too long

From my understanding a CLOB leave maximum string size of 2 GB. And on top, my xml string is not greater than 2 GB (I cannot display the xml data string, refers to the business). So why I get the error too long string literal.
For the above, I fault the XML into several parts and run the PLSQL, then it gives no error.
Please advice.

Published by: 934451 on November 8, 2012 07:06

Published by: 934451 on November 8, 2012 07:07
From my understanding a CLOB leave maximum string size of 2 GB.

Not exactly:
http://docs.Oracle.com/CD/E11882_01/AppDev.112/e25519/datatypes.htm#CHDDCGEE

but this isn't the real problem.

The error is about the "string literal" size, there is a limitation too:
http://docs.Oracle.com/CD/E11882_01/server.112/e17766/pcmus.htm#sthref18132
```
PLS-00172: string literal too long
    Cause: The string literal was longer than 32767 bytes.
    Action: Use a string literal of at most 32767 bytes.
```
For the above, I fault the XML into several parts and run the PLSQL, then it gives no error.

Is this a real case of production or you just test?
In practice, we should first save the file in a variable/column CLOB (or XMLType) and then reference the content from there.

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

Similar Questions

Maybe you are looking for