DBMS_SQL.PARSE Question
Hi,
From the PL/SQL packages doc:
DBMS_SQL.PARSE Procedure
This procedure parses the given statement in the given cursor.
All statements are parsed immediately. In addition, DDL
statements are run immediately when parsed.Any reason as to why DDL statements are executed when passed
to DBMS_SQL.PARSE ?
Rgds.
Amogh
I think you are asking for alternate of dbms_sql.parse,
so you can use native dynamic sql:
SQL> create or replace procedure exec_ddl
2 as
3 begin
4 execute immediate 'create table sample_table(x varchar2(1))' ;
5 end;
6 /
Procedure created.
SQL> exec exec_ddl
PL/SQL procedure successfully completed.
SQL> desc sample_table
Name Null? Type
X VARCHAR2(1)
Similar Messages
-
Hi Team ,
The below inesrt query returns an error message " exact fetch returns more than one row " . How can I found the insert query statement on the below query in the DBMS_SQL.PARSE ?
Code :
v_query(1) := 'insert into ' || gv_table_name || ' ' ;
v_query(2) :=' select ';
v_query(3) := v_counter || '+ rownum , ';
v_query(4) :='''020'' || ';
v_query(5) :='lpad(p.fixed_cont_code,11,''0'') || ';
v_query(6) :='rpad(NVL(ref.bridge_code_1,'' ''),15,'' '') || ';
v_query(7) :='rpad(NVL(ref.bridge_code_2,'' ''),15,'' '') || ';
v_query(8) :='rpad(NVL(ref.bridge_code_3,'' ''),15,'' '') || ';
v_query(9) :='LPAD(NVL(ref.bridge_code_4,'' ''),15,'' '') || ';
v_query(10) :='LPAD(NVL(ref.bridge_code_5,'' ''),15,'' '') || ';
v_query(11) :='LPAD(NVL(ref.bridge_code_6,'' ''),15,'' '') || ';
v_query(12) :='LPAD(NVL(ref.bridge_code_7,'' ''),15,'' '') || ';
v_query(13) :='LPAD(NVL(ref.bridge_code_8,'' ''),15,'' '') || ';
v_query(14) :='LPAD(NVL(ref.bridge_code_9,'' ''),15,'' '') || ';
v_query(15) :='LPAD(NVL(ref.bridge_code_10,'' ''),15,'' '') || ';
v_query(16) :='rpad(prn.prod_short_name,80,'' '') || ';
v_query(17) :='rpad(nvl(p.pack_description,'' ''),80,'' '') || ';
v_query(18) :='lpad(NVL(get_prod_org_code(p.market_abbr,p.prod_code,''' || GV_PERIOD_START_DATE ||'''),''0''),5,''00'') || ';
--v_query(19) :='lpad(''0'',5,''0'') || ';
v_query(19) :='lpad(NVL(get_prod_org_dist_code(p.market_abbr,p.prod_code,''' || GV_PERIOD_START_DATE ||'''),''0''),5,''00'') || ';
v_query(20) :='RPAD(NVL(trim(ref.class_code_1),''Z98A2''),12,'' '') || ';
v_query(21) :='RPAD(NVL(trim(ref.class_code_2),''98A2Z''),12,'' '') || ';
v_query(22) :='RPAD(NVL(ref.class_code_3,'' ''),12,'' '') || ';
v_query(23) :='RPAD(NVL(ref.class_code_4,'' ''),12,'' '') || ';
v_query(24) :='RPAD(NVL(ref.class_code_5,'' ''),12,'' '') || ';
v_query(25) :='RPAD(NVL(ref.class_code_6,'' ''),12,'' '') || ';
v_query(26) :='RPAD(NVL(ref.class_code_7,'' ''),12,'' '') || ';
v_query(27) :='RPAD(NVL(ref.class_code_8,'' ''),12,'' '') || ';
v_query(28) :='RPAD(NVL(ref.class_code_9,'' ''),12,'' '') || ';
v_query(29) :='RPAD(NVL(ref.class_code_10,'' ''),12,'' '') || ';
v_query(30) :='RPAD(NVL(ref.class_code_11,'' ''),12,'' '') || ';
v_query(31) :='RPAD(NVL(ref.class_code_12,'' ''),12,'' '') || ';
v_query(32) :='RPAD(NVL(ref.class_code_13,'' ''),12,'' '') || ';
v_query(33) :='RPAD(NVL(ref.class_code_14,'' ''),12,'' '') || ';
v_query(34) :='RPAD(NVL(ref.class_code_15,'' ''),12,'' '') || ';
v_query(35) :='RPAD(NVL(ref.prod_flag_1,'' ''),12,'' '') || ';
v_query(36) :='RPAD(NVL(ref.prod_flag_2,'' ''),12,'' '') || ';
v_query(37) :='RPAD(NVL(ref.prod_flag_3,'' ''),12,'' '') || ';
v_query(38) :='RPAD(NVL(ref.prod_flag_4,'' ''),12,'' '') || ';
v_query(39) :='RPAD(NVL(ref.prod_flag_5,'' ''),12,'' '') || ';
v_query(40) :='RPAD(NVL(ref.prod_flag_6,'' ''),12,'' '') || ';
v_query(41) :='RPAD(NVL(ref.prod_flag_7,'' ''),12,'' '') || ';
v_query(42) :='RPAD(NVL(ref.prod_flag_8,'' ''),12,'' '') || ';
v_query(43) :='RPAD(NVL(ref.prod_flag_9,'' ''),12,'' '') || ';
v_query(44) :='RPAD(NVL(ref.prod_flag_10,'' ''),12,'' '') || ';
v_query(45) :='RPAD(NVL(ref.prod_flag_11,'' ''),12,'' '') || ';
v_query(46) :='RPAD(NVL(ref.prod_flag_12,'' ''),12,'' '') || ';
v_query(47) :='RPAD(NVL(ref.prod_flag_13,'' ''),12,'' '') || ';
v_query(48) :='RPAD(NVL(ref.prod_flag_14,'' ''),12,'' '') || ';
v_query(49) :='RPAD(NVL(ref.prod_flag_15,'' ''),12,'' '') || ';
v_query(50) :='RPAD(NVL(ref.prod_flag_16,'' ''),12,'' '') || ';
v_query(51) :='RPAD(NVL(ref.prod_flag_17,'' ''),12,'' '') || ';
v_query(52) :='RPAD(NVL(ref.prod_flag_18,'' ''),12,'' '') || ';
v_query(53) :='RPAD(NVL(ref.prod_flag_19,'' ''),12,'' '') || ';
v_query(54) :='RPAD(NVL(ref.prod_flag_20,'' ''),12,'' '') || ';
v_query(55) :='RPAD(NVL(ref.prod_flag_21,'' ''),12,'' '') || ';
v_query(56) :='RPAD(NVL(ref.prod_flag_22,'' ''),12,'' '') || ';
v_query(57) :='RPAD(NVL(ref.prod_flag_23,'' ''),12,'' '') || ';
v_query(58) :='RPAD(NVL(ref.prod_flag_24,'' ''),12,'' '') || ';
v_query(59) :='RPAD(NVL(ref.prod_flag_25,'' ''),12,'' '') || ';
v_query(60) :='RPAD(NVL(ref.pack_flag_1,'' ''),12,'' '') || ';
v_query(61) :='RPAD(NVL(ref.pack_flag_2,'' ''),12,'' '') || ';
v_query(62) :='RPAD(NVL(ref.pack_flag_3,'' ''),12,'' '') || ';
v_query(63) :='RPAD(NVL(ref.pack_flag_4,'' ''),12,'' '') || ';
v_query(64) :='RPAD(NVL(ref.pack_flag_5,'' ''),12,'' '') || ';
v_query(65) :='RPAD(NVL(ref.pack_flag_6,'' ''),12,'' '') || ';
v_query(66) :='RPAD(NVL(ref.pack_flag_7,'' ''),12,'' '') || ';
v_query(67) :='RPAD(NVL(ref.pack_flag_8,'' ''),12,'' '') || ';
v_query(68) :='RPAD(NVL(ref.pack_flag_9,'' ''),12,'' '') || ';
v_query(69) :='RPAD(NVL(ref.pack_flag_10,'' ''),12,'' '') || ';
v_query(70) :='RPAD(NVL(ref.pack_flag_11,'' ''),12,'' '') || ';
v_query(71) :='RPAD(NVL(ref.pack_flag_12,'' ''),12,'' '') || ';
v_query(72) :='RPAD(NVL(ref.pack_flag_13,'' ''),12,'' '') || ';
v_query(73) :='RPAD(NVL(ref.pack_flag_14,'' ''),12,'' '') || ';
v_query(74) :='RPAD(NVL(ref.pack_flag_15,'' ''),12,'' '') || ';
v_query(75) :='RPAD(NVL(ref.pack_flag_16,'' ''),12,'' '') || ';
v_query(76) :='RPAD(NVL(ref.pack_flag_17,'' ''),12,'' '') || ';
v_query(77) :='RPAD(NVL(ref.pack_flag_18,'' ''),12,'' '') || ';
v_query(78) :='RPAD(NVL(ref.pack_flag_19,'' ''),12,'' '') || ';
v_query(79) :='RPAD(NVL(ref.pack_flag_20,'' ''),12,'' '') || ';
v_query(80) :='RPAD(NVL(ref.pack_flag_21,'' ''),12,'' '') || ';
v_query(81) :='RPAD(NVL(ref.pack_flag_22,'' ''),12,'' '') || ';
v_query(82) :='RPAD(NVL(ref.pack_flag_23,'' ''),12,'' '') || ';
v_query(83) :='RPAD(NVL(ref.pack_flag_24,'' ''),12,'' '') || ';
v_query(84) :='RPAD(NVL(ref.pack_flag_25,'' ''),12,'' '') || ';
v_query(85) :='nvl(lpad(NVL(ref.pack_price_1,''0''),13,''0''),''0000000000000'') || ';
v_query(86) :='nvl(ref.effective_date_1,''00000000'') || ';
v_query(87) :='nvl(lpad(NVL(ref.pack_price_2,''0''),13,''0''),''0000000000000'') || ';
v_query(88) :='nvl(ref.effective_date_2,''00000000'') || ';
v_query(89) :='nvl(lpad(NVL(ref.pack_price_3,''0''),13,''0''),''0000000000000'') || ';
v_query(90) :='nvl(ref.effective_date_3,''00000000'') || ';
v_query(91) :='nvl(lpad(NVL(ref.pack_price_4,''0''),13,''0''),''0000000000000'') || ';
v_query(92) :='nvl(ref.effective_date_4,''00000000'') || ';
v_query(93) :='nvl(lpad(NVL(ref.pack_price_5,''0''),13,''0''),''0000000000000'') || ';
v_query(94) :='nvl(ref.effective_date_5,''00000000'') || ';
v_query(95) :='nvl(lpad(NVL(ref.pack_price_6,''0''),13,''0''),''0000000000000'') || ';
v_query(96) :='nvl(ref.effective_date_6,''00000000'') || ';
v_query(97) :='nvl(lpad(NVL(ref.pack_price_7,''0''),13,''0''),''0000000000000'') || ';
v_query(98) :='nvl(ref.effective_date_7,''00000000'') || ';
v_query(99) :='nvl(lpad(NVL(ref.pack_price_8,''0''),13,''0''),''0000000000000'') || ';
v_query(100) :='nvl(ref.effective_date_8,''00000000'') || ';
v_query(101) :='nvl(lpad(NVL(ref.pack_price_9,''0''),13,''0''),''0000000000000'') || ';
v_query(102) :='nvl(ref.effective_date_9,''00000000'') || ';
v_query(103) :='nvl(lpad(NVL(ref.pack_price_10,''0''),13,''0''),''0000000000000'') || ';
v_query(104) :='nvl(ref.effective_date_10,''00000000'') || ';
v_query(105) :='lpad(nvl(NDF_PAV(p.market_abbr,p.fixed_cont_code,''PEF'',''' || GV_PERIOD_START_DATE ||'''),''0''),15,''0'') || ';
v_query(106) :='RPAD(''0'',15,''0'') || ';
v_query(107) :='lpad(nvl(NDF_PAV(p.market_abbr,p.fixed_cont_code,''QLIM'',''' || GV_PERIOD_START_DATE ||'''),''0''),15,''0'') || ';
v_query(108) :='NVL(TO_CHAR(PRD.PROD_LAUNCH_DATE,''YYYYMMDD''),''00000000'') || ';
v_query(109) :='NVL(TO_CHAR(PCKD.PACK_LAUNCH_DATE,''YYYYMMDD''),''00000000'') || ';
v_query(110) :='NVL(TO_CHAR(PACK_OUT_OF_TRADE_DATE,''YYYYMMDD''),''00000000'') || ';
v_query(111) :='nvl(ref.study_connection_1,'' '') || ';
v_query(112) :='nvl(ref.study_connection_2,'' '') || ';
v_query(113) :='nvl(ref.study_connection_3,'' '') || ';
v_query(114) :='nvl(ref.study_connection_4,'' '') || ';
v_query(115) :='nvl(ref.study_connection_5,'' '') || ';
v_query(116) :='nvl(ref.study_connection_6,'' '') || ';
v_query(117) :='nvl(ref.study_connection_7,'' '') || ';
v_query(118) :='nvl(ref.study_connection_8,'' '') || ';
v_query(119) :='nvl(ref.study_connection_9,'' '') || ';
v_query(120) :='nvl(ref.study_connection_10,'' '') || ';
v_query(121) :='nvl(ref.study_connection_11,'' '') || ';
v_query(122) :='nvl(ref.study_connection_12,'' '') || ';
v_query(123) :='nvl(ref.study_connection_13,'' '') || ';
v_query(124) :='nvl(ref.study_connection_14,'' '') || ';
v_query(125) :='nvl(ref.study_connection_15,'' '') || ';
v_query(126) :='nvl(ref.study_connection_16,'' '') || ';
v_query(127) :='nvl(ref.study_connection_17,'' '') || ';
v_query(128) :='nvl(ref.study_connection_18,'' '') || ';
v_query(129) :='nvl(ref.study_connection_19,'' '') || ';
v_query(130) :='nvl(ref.study_connection_20,'' '') || ';
v_query(131) :='nvl(rpad(ndf_pmcc(p.market_abbr,p.fixed_cont_code,''' || v_market_abbr ||'FD'',''' || GV_PERIOD_START_DATE ||'''),20,'' ''),lpad('' '',20,'' '')) || ';
v_query(132) :='LPAD(NVL(PACK_SIZE,''0''),8,''0'') || ';
v_query(133) :='''00000'' || ';
v_query(134) :='rpad(NVL(decode(rpad(nvl(p.weight_unit_absolute_strength,''0''),2,''0''),''00'',''0000'',lpad(nvl(to_char(p.absolute_strength_measure),''0''),4,''0'')),''0000''),4,'' '') || ';
v_query(135) :=' '' '' || rpad(nvl(p.weight_unit_absolute_strength,'' ''),2,'' '') || ';
v_query(136) :='decode(rpad(nvl(p.weight_unit_absolute_strength,''0''),2,''0''),''00'',''00000000'',lpad(nvl(to_char(p.absolute_strength_measure*1000),''0''),8,''0'')) || ';
v_query(137) :='RPad(nvl(p.weight_unit_absolute_strength,'' ''),5,'' '') || ';
v_query(138) :='decode(rpad(nvl(p.weight_unit_relative_strength,''0''),2,''0''),''00'',''00000000'',lpad(nvl(to_char(p.relative_strength_measure*1000),''0''),8,''0'')) || ';
v_query(139) :='RPad(nvl(p.weight_unit_relative_strength,'' ''),5,'' '') || ';
v_query(140) :='''00000000'' || ';
v_query(141) :=''' '' || ';
v_query(142) :='''00000000'' || ';
v_query(143) :=''' '' || ';
v_query(144) :='decode(pack_weight_measure,null,''00000000'',lpad(pack_weight_measure*1000,8,''0'')) || ';
v_query(145) :='rpad(nvl(p.weight_unit_pack,'' ''),5,'' '') || ';
v_query(146) := 'rpad(nvl( ' ;
v_query(147) := 'ndf_pmcc(p.market_abbr, ' ;
v_query(148) := ' p.fixed_cont_code, ' ;
v_query(149) := '''ADDST'', ''' ;
v_query(150) := GV_PERIOD_START_DATE ||'''), '' '')' ;
v_query(151) := ' ,12,'' '' ) || ' ;
v_query(152) :='rpad(nvl(p.ndf_pack_add_info,'' ''),8,'' '') || ';
v_query(153) :='nvl(decode(p.pin_elh_status,''ACTIVE'','' '',''Z'' ),'' '') || lpad('' '',100,'' '') ';
v_query(154) :='from pack p , PROD_NAME prn, PROD_DATE PRD, PACK_DATE PCKD, prod,';
v_query(155) :=' lpin_cpi_20_ref_data ref ';
v_query(156) :=' where ';
v_query(157) :=' p.market_abbr = ''' || v_market_abbr ||''' and ';
v_query(158) :=' p.market_abbr = ref.market_abbr and';
v_query(159) :=' p.fixed_cont_code = ref.fixed_cont_code and';
v_query(160) :=' p.PIN_ELH_STATUS <> ''RESEARCH'' and';
v_query(161) :=' prod.prod_code = p.prod_code and';
v_query(162) :=' prod.market_abbr = p.market_abbr and';
v_query(163) :=' prod.PIN_ELH_STATUS <> ''RESEARCH'' and';
v_query(164) :=' NDF_confmkt2 (p.market_abbr,p.fixed_cont_code,''' || GV_PERIOD_START_DATE ||''')>0 and ';
v_query(165) :=' p.market_abbr = prn.market_abbr and';
v_query(166) :=' p.prod_code = prn.prod_code and';
v_query(167) :=' p.market_abbr = PRD.market_abbr and';
v_query(168) :=' p.prod_code = PRD.prod_code AND';
v_query(169) :=' p.market_abbr = PCKD.market_abbr and';
v_query(170) :=' p.FIXED_CONT_CODE = PCKD.FIXED_CONT_CODE';
v_query(171) :=' AND row_current_check (prd.valid_from_date, prd.valid_to_date, ''' || GV_PERIOD_START_DATE ||''') = 0';
v_query(172) :=' AND row_current_check (prn.valid_from_date, prn.valid_to_date, ''' || GV_PERIOD_START_DATE ||''') = 0';
v_query(173) :=' AND row_current_check (pckd.valid_from_date, pckd.valid_to_date, ''' || GV_PERIOD_START_DATE ||''') = 0';
v_query(174) :=' order by p.fixed_cont_code ';
DBMS_SQL.PARSE (v_cursor_handle, v_query,1,174,TRUE,dbms_sql.native);
gv_total_packs :=dbms_sql.execute(v_cursor_handle);
DBMS_SQL.CLOSE_CURSOR (v_cursor_handle);I will not even begin to try to help you ... here's why.
1. You did not read the FAQ and learn the proper way to post to the forums using tags for listings.
2. I have on idea what your version number is.
3. I'm not going to read a kilometer of code to try to find an issue ... create a simple test case that recreates the issue.
4. You didn't think the error important enough to post so I've no idea what is actually going on.
Please fix this thread and likely I or someone else will be able to help you.
But why are you using DBMS_SQL and not native dynamic SQL? That is really my first question. -
Using DBMS_SQL.PARSE
Hi,
I am trying to write a proc. for dynamically saving data in a table.
My dynamic sql is stored in str_SQL (varchar2(4000) is more than 4000 char.
How can I use it.
DBMS_SQL.PARSE
(cur, str_Qry, DBMS_SQL.NATIVE);
What is the way out.
Regards
DeepakI got your question and saying that all you need to do is this:
str_sql VARCHAR2(32000);Your concern as of now is that the value being assigned to str_sql can be more than 4000 characters, to which I am saying that increase the size of your variable as VARCHAR2 can go upto 32767 characters inside a PL/SQL block. This will solve your problem, assuming that the length of the query string is not more than 32000.
I have used it myself and that's why I am sure that this concern of yours will be addressed.
Thanks,
Ankur -
Error when using DBMS_SQL.parse
Has anyone ever ran into this error "ORA-00932: inconsistent datatypes: expected NUMBER got DATE" when using DBMS_SQL.parse? I'm trying to pass in a sql statement that includes date columns but it keeps failing during the parse step. If I put a "to_char" around the dates it works fine.
Any ideas?
declare
l_cursor PLS_INTEGER;
l_rows PLS_INTEGER;
l_col_cnt PLS_INTEGER;
l_desc_tab DBMS_SQL.desc_tab;
l_buffer CLOB;
v_query clob;
l_file UTL_FILE.file_type;
g_sep VARCHAR2(5) := ',';
BEGIN
l_cursor := DBMS_SQL.open_cursor;
v_query := 'SELECT CREATED FROM DBA_USERS';
DBMS_SQL.parse(l_cursor, v_query, DBMS_SQL.native);
DBMS_SQL.describe_columns(l_cursor, l_col_cnt, l_desc_tab);
FOR i IN 1 .. l_col_cnt
LOOP
DBMS_SQL.define_column(l_cursor, i, l_buffer);
END LOOP;
l_rows := DBMS_SQL.execute(l_cursor);
-- Output the column names.
FOR i IN 1 .. l_col_cnt
LOOP
IF i > 1 THEN
UTL_FILE.put(l_file, g_sep);
END IF;
UTL_FILE.put(l_file, l_desc_tab(i).col_name);
END LOOP;
UTL_FILE.new_line(l_file);
-- Output the data.
LOOP
EXIT WHEN DBMS_SQL.fetch_rows(l_cursor) = 0;
FOR i IN 1 .. l_col_cnt
LOOP
IF i > 1 THEN
UTL_FILE.put(l_file, g_sep);
END IF;
DBMS_SQL.COLUMN_VALUE(l_cursor, i, l_buffer);
-- Check for column data type. If "character" data type enclose in quotes
-- 1 = VARCHAR2 and NVARCHAR2, 96 = CHAR and NCHAR, 112 = CLOB
IF l_desc_tab(i).col_type IN (1, 96, 112) THEN
l_buffer := '"' || l_buffer || '"';
END IF;
UTL_FILE.put(l_file, l_buffer);
END LOOP;
UTL_FILE.new_line(l_file);
END LOOP;
UTL_FILE.fclose(l_file);
EXCEPTION
WHEN OTHERS THEN
IF UTL_FILE.is_open(l_file) THEN
UTL_FILE.fclose(l_file);
END IF;
IF DBMS_SQL.is_open(l_cursor) THEN
DBMS_SQL.close_cursor(l_cursor);
END IF;
RAISE;
END;Edited by: jpvybes on Jun 6, 2013 3:47 PM>
Has anyone ever ran into this error "ORA-00932: inconsistent datatypes: expected NUMBER got DATE" when using DBMS_SQL.parse? I'm trying to pass in a sql statement that includes date columns but it keeps failing during the parse step. If I put a "to_char" around the dates it works fine.
>
No - it is NOT failing on the parse step. If you comment out various sections of the code you will find that your loop is causing the problem.
Comment out this loop and there is NO exception.
l_buffer CLOB;
FOR i IN 1 .. l_col_cnt
LOOP
DBMS_SQL.define_column(l_cursor, i, l_buffer);
END LOOP;Do you now see the problem?
You are using 'define_column' and passing 'l_buffer' which is a CLOB. But this is your query
v_query := 'SELECT CREATED FROM DBA_USERS';And that 'CREATED' column in the query is a DATE.
Why are you defining a column as a CLOB when the cursor column is a DATE?
See the example3 in Chapter 100 DBMS_SQL in the Packages and Types doc. It shows an example that includes a DATE column.
http://docs.oracle.com/cd/B19306_01/appdev.102/b14258/d_sql.htm#i996963 -
DBMS_SQL.PARSE Not Accepting My Query
hi all ,
i am trying to generate a ascii file from my procedure ..
my ascii file should contain data like the below
"7200", "SMITH","10-AUG-1981"
DBMS_SQL.PARSE(l_cursor,'SELECT '"'||empno||'"'||','||'"'||ename||'"'||','||'"'||dob||'"'FROM EMP',dbms_sql.native);
PLS-00103: Encountered the symbol "'||empno||'" when expecting one of the
following:
) , * & | = - + < / > at in is mod remainder not rem => ..
please give me any idea how to resolve this ..One sec ..i have again a small doubt can we pass parameters to this query
DBMS_SQL.PARSE(l_cursor,q'[SELECT '"'||empno||'","'||ename||'","'||dob||'"' FROM EMP]',dbms_sql.native);
i want to include where condition like FROM_DATE >= P_FROM_DATE
TO_DATE <=P_TO_DATE
These P_FROM_DATE and P_TO_DATE i am passing as input parameters to my procedures ..can i use them inside this query ? -
DBMS_SQL.PARSE with PL/SQL types
Hi
I need to use DBMS_SQL.PARSE with PL/SQL types defined in a package.
I tried with a type record in a declare ..begin..end script but I got an error ..(on second parameter):
DBMS_SQL.PARSE(cursor_name, XXXXX, DBMS_SQL.NATIVE);
It's possible?
WIth SQL types defined at schema level it's works (es. Objects types) .
If it's not possible, how can I resolve?
StefanoAgain, please post what XXXXX is. In order to use package declared types:
SQL> create or replace
2 package pkg1
3 is
4 type emp_rec
5 is record (
6 empno number,
7 ename varchar2(10)
8 );
9 type emp_rec_tbl
10 is
11 table of emp_rec
12 index by pls_integer;
13 g_emp_rec_tbl pkg1.emp_rec_tbl;
14 end;
15 /
Package created.
SQL> declare
2 v_cur integer;
3 v_sql varchar2(1000);
4 begin
5 v_cur := dbms_sql.open_cursor(2);
6 v_sql := 'begin
7 select empno,
8 ename
9 bulk collect
10 into pkg1.g_emp_rec_tbl
11 from emp
12 where job = ''CLERK'';
13 end;';
14 dbms_sql.parse(
15 v_cur,
16 v_sql,
17 dbms_sql.native
18 );
19 end;
20 /
PL/SQL procedure successfully completed.
SQL>
SY. -
Dbms_sql.parse: varchar2a version does NOT throw ORA-24344
I'm trying to execute some generated code in 10.2. using the varchar2a version of dbms_sql.parse.
This works fine, but when the there is something wrong in the generated code, I do not get an exception (I do get it with the varchar2 version).
So when I run the following example, the first call to dbms_sql.parse creates an invalid package, but only the second call will actually throw an exception:
DECLARE
v_cur INTEGER;
v_sql dbms_sql.varchar2a;
BEGIN
v_cur := DBMS_SQL.open_cursor;
v_sql(1) := 'CREATE OR REPLACE PACKAGE xxx AS a ###; END;'; -- invalid SQL
dbms_sql.parse(v_cur, v_sql, 1, 1, FALSE, dbms_sql.native);
dbms_output.put_line ('ERROR: should have failed');
dbms_sql.parse(v_cur, v_sql(1), dbms_sql.native);
dbms_sql.close_cursor(v_cur);
EXCEPTION
WHEN OTHERS THEN
dbms_sql.close_cursor( v_cur );
dbms_output.put_line ('OK: ' || SQLERRM );
END;
Can anybody reproduce/explain this?
Thanks!Here is the code I am running ...
CREATE OR REPLACE PROCEDURE p_sql_valid_or_not_cnt
(vSQL IN VARCHAR2, vValid OUT NUMBER, vMessage OUT VARCHAR2, vCount OUT NUMBER) IS
-- Purpose: Returns 0 in vvalid if SQL is valid, else returns -1. Returns row count when SQL is valid.
-- Parameters:
-- IN : vSQL
-- OUT : vValid
-- OUT : vMessage
-- OUT : vCount
cur INTEGER := DBMS_SQL.OPEN_CURSOR;
fdbk INTEGER;
BEGIN
DBMS_SQL.PARSE (cur, vSQL, DBMS_SQL.NATIVE);
fdbk := DBMS_SQL.EXECUTE (cur);
vCount := 0;
LOOP /* Fetch next row. Exit when done. */
EXIT WHEN DBMS_SQL.FETCH_ROWS (cur) = 0;
vCount := vCount + 1;
END LOOP;
vValid := 0;
vMessage := 'No errors';
DBMS_SQL.CLOSE_CURSOR (cur);
END p_sql_valid_or_not_cnt;
To run ...
set serveroutput on
declare
i number;
m varchar2(500);
c number;
begin
p_sql_valid_or_not_cnt('SELECT * FROM TAB where 1 <> 1',i,m,c);
DBMS_OUTPUT.PUT_LINE(i);
DBMS_OUTPUT.PUT_LINE(m);
DBMS_OUTPUT.PUT_LINE(c);
end;
This runs fine.
But when I try to access an object from a remote server using DB link. I get the error ...
set serveroutput on
declare
i number;
m varchar2(500);
c number;
begin
p_sql_valid_or_not_cnt('SELECT * FROM REMOTE_SCHEMA.T_REMOTE@REMOTE_SERVER where 1 <> 1',i,m,c);
DBMS_OUTPUT.PUT_LINE(i);
DBMS_OUTPUT.PUT_LINE(m);
DBMS_OUTPUT.PUT_LINE(c);
end;
declare
ERROR at line 1:
ORA-24374: define not done before fetch or execute and fetch
ORA-06512: at "SYS.DBMS_SYS_SQL", line 1125
ORA-06512: at "SYS.DBMS_SQL", line 328
ORA-06512: at "IMEPAS.P_SQL_VALID_OR_NOT_CNT", line 16
ORA-06512: at line 6
I can run the SQL that I am passing as vSQL directly in SQLPLUS ...
This code in itself works.
SELECT * FROM
REMOTE_SCHEMA.T_REMOTE@REMOTE_SERVER
where 1 <> 1;
The user I am using to logon to my server is also there on REMOTE_SERVER.
The DB LINK is created by CONNECTED USER option. The user on REMOTE_SERVER has explict select access on the table (not via role) I am accessing.
Any help would be much appreciated. -
DBMS_SQL.PARSE to access remote objects
I am using following code in a procedure ...
DBMS_SQL.PARSE (cur, vSQL, DBMS_SQL.NATIVE);
where variable vSQL can contain a remote object.
A DB link (with Fixed User option) exists to access that database.
The DB link is working. The remote object is accessible outside this procedure.
When this command is executed, I get ...
ORA-24374: define not done before fetch or execute and fetch
... error.
Can DBMS_SQL handle remote objects?
Oracle version is 9.2.0.5.0
Any help would be greatly appreciated.Here is the code I am running ...
CREATE OR REPLACE PROCEDURE p_sql_valid_or_not_cnt
(vSQL IN VARCHAR2, vValid OUT NUMBER, vMessage OUT VARCHAR2, vCount OUT NUMBER) IS
-- Purpose: Returns 0 in vvalid if SQL is valid, else returns -1. Returns row count when SQL is valid.
-- Parameters:
-- IN : vSQL
-- OUT : vValid
-- OUT : vMessage
-- OUT : vCount
cur INTEGER := DBMS_SQL.OPEN_CURSOR;
fdbk INTEGER;
BEGIN
DBMS_SQL.PARSE (cur, vSQL, DBMS_SQL.NATIVE);
fdbk := DBMS_SQL.EXECUTE (cur);
vCount := 0;
LOOP /* Fetch next row. Exit when done. */
EXIT WHEN DBMS_SQL.FETCH_ROWS (cur) = 0;
vCount := vCount + 1;
END LOOP;
vValid := 0;
vMessage := 'No errors';
DBMS_SQL.CLOSE_CURSOR (cur);
END p_sql_valid_or_not_cnt;
To run ...
set serveroutput on
declare
i number;
m varchar2(500);
c number;
begin
p_sql_valid_or_not_cnt('SELECT * FROM TAB where 1 <> 1',i,m,c);
DBMS_OUTPUT.PUT_LINE(i);
DBMS_OUTPUT.PUT_LINE(m);
DBMS_OUTPUT.PUT_LINE(c);
end;
This runs fine.
But when I try to access an object from a remote server using DB link. I get the error ...
set serveroutput on
declare
i number;
m varchar2(500);
c number;
begin
p_sql_valid_or_not_cnt('SELECT * FROM REMOTE_SCHEMA.T_REMOTE@REMOTE_SERVER where 1 <> 1',i,m,c);
DBMS_OUTPUT.PUT_LINE(i);
DBMS_OUTPUT.PUT_LINE(m);
DBMS_OUTPUT.PUT_LINE(c);
end;
declare
ERROR at line 1:
ORA-24374: define not done before fetch or execute and fetch
ORA-06512: at "SYS.DBMS_SYS_SQL", line 1125
ORA-06512: at "SYS.DBMS_SQL", line 328
ORA-06512: at "IMEPAS.P_SQL_VALID_OR_NOT_CNT", line 16
ORA-06512: at line 6
I can run the SQL that I am passing as vSQL directly in SQLPLUS ...
This code in itself works.
SELECT * FROM
REMOTE_SCHEMA.T_REMOTE@REMOTE_SERVER
where 1 <> 1;
The user I am using to logon to my server is also there on REMOTE_SERVER.
The DB LINK is created by CONNECTED USER option. The user on REMOTE_SERVER has explict select access on the table (not via role) I am accessing.
Any help would be much appreciated. -
Dbms_sql.parse and ora-01704: string literal too long
I am using the version of dbms_sql.parse that is supposed to take large sql statements but I still get the ora-1704 error when the total length of the statement exceeds 4000k...
Why?
This is my test code
declare
v_sql varchar2(32000) := 'select '''|| lpad('A',8000,'M') || ''' from dual';
l_length number := 250;
l_number number := round(length(v_sql)/l_length) + 1;
l_lines DBMS_SQL.varchar2s;
l_cur PLS_INTEGER := DBMS_SQL.open_cursor;
v_temp varchar2(255);
begin
for i in 1..l_number
loop
l_lines(l_lines.count+1) := substr(v_sql,(i-1)*l_length+1, l_length);
end loop;
DBMS_SQL.parse ( c => l_cur
,statement => l_lines
,lb => l_lines.FIRST
,ub => l_lines.LAST
,lfflg => false
,language_flag =>DBMS_SQL.native
DBMS_SQL.close_cursor (l_cur);
end;sorry for the bad layout, I remember having a tag on this forum but it's no longer working?
Edited by: Wendy Tromp on Jul 22, 2009 10:13 AMthe literal you use in the SELECT statement is simply to long.
You can't execute this statement:
select 'MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMA' from dualThe literal is a CHAR and the SQL limit for that is 4000, this one is 8000
btw, the markup for your code is (curly brackets - lower case - before and after your code) -
DBMS_SQL.PARSE + CLOB
Hi,
I am using:
DBMS_SQL.PARSE ( c IN INTEGER, statement IN VARCHAR2, language_flag IN INTEGER);
I have to parse very very big pl/sql blocks. So I have to put into statement, paremeter which has CLOB type.
When my statement is not too big everything works well. But when my block has 5200 lines it gives me error:
numeric or value error.
I think my block is too big...
can anybody help me?
how to fix ma problem?
Grzegorzhi all,
I have the same problem with some differences
when the string is too big it give me error no parse statement
this not happened when the string is less than 4000 char
when I assign my string (with clob datatype) to the variable l_lines (DBMS_SQL.varchar2s datatype) it give me error: PLS-00382: expression is of wrong type
I use oracle 10g
thanks -
DBMS_SQL.parse error when working with string 32k
Hi,
In order to execute a dynamic string > 32 k , i followed metalink note: 77470.1 :" How to Execute DML and DDL Statements Larger than 32k Using dbms_sql "
When running a procedure to dynamicaly recreate a view i got the following error message.
Can one suggest what to do ?
Thanks
begin
2 recreate_dynamic_views(to_date('01/01/2008','dd/mm/yyyy'),
3 to_date('01/05/2009','dd/mm/yyyy'),
4 to_date('01/12/2006','dd/mm/yyyy')
5 );
6 end;
7 /
prod_num_of_months=16
begin
ERROR at line 1:
ORA-00933: SQL command not properly ended
ORA-06512: at "SYS.DBMS_SYS_SQL", line 1600
ORA-06512: at "SYS.DBMS_SQL", line 26
ORA-06512: at "MYUSER.RECREATE_DYNAMIC_VIEWS", line 87
ORA-06512: at line 2
Line 87 is :
DBMS_SQL.parse (cursor_id, create_stmt, 1, ub, TRUE, DBMS_SQL.native);
The source code :
CREATE OR REPLACE procedure recreate_dynamic_views(p_prod_from_month_include date,
p_prod_until_month_include date,
p_hist_until_month_include date)
is
-- example : exec recreate_dynamic_views(to_date('01/01/2008','dd/mm/yyyy'),
-- to_date('01/05/2009','dd/mm/yyyy'),
-- to_date('01/12/2006','dd/mm/yyyy'))
CURSOR c (v_instance_type VARCHAR2)
IS
SELECT view_name, view_text, month_exp, instance_type, start_from,
complex_view, union_with,
ROUND(months_between(to_date(p_prod_until_month_include,'DD/MM/YYYY'),
to_date(p_prod_from_month_include,'DD/MM/YYYY')
) prod_num_of_months,
months_between(to_date(p_hist_until_month_include,'DD/MM/YYYY'),
to_date(START_FROM,'DD/MM/YYYY')
) hist_num_of_months
FROM list_of_views
where instance_type = v_instance_type
and view_name = 'V_MY_CALLS';
v_str_header VARCHAR2 (32000);
v_str VARCHAR2 (32000);
v1 VARCHAR2 (4);
v_month VARCHAR2 (200);
v_instance VARCHAR2 (20);
v_instance_type VARCHAR2 (20);
v_start_from VARCHAR2 (10);
v_num_of_month NUMBER;
v_its_new_view VARCHAR2 (1) := 'Y';
create_stmt DBMS_SQL.varchar2a;
ub NUMBER := 0;
cursor_id INTEGER;
ret_val INTEGER;
BEGIN
dbms_output.enable(1000000);
--DBMS_OUTPUT.put_line ('start hir');
SELECT UPPER (instance_name)
INTO v_instance
FROM v$instance;
--DBMS_OUTPUT.put_line ('v_instance=' || v_instance);
IF UPPER (v_instance) LIKE '%HST%'
THEN
v_instance_type := 'HISTORY';
ELSE
v_instance_type := 'BILLING';
END IF;
IF v_instance_type = 'BILLING'
THEN
for c_rec in c(v_instance_type) loop
v_str_header := null;
v_str := null;
ub := 0;
ret_val := null;
dbms_output.put_line('prod_num_of_months='||c_rec.prod_num_of_months);
for i in 1..(c_rec.prod_num_of_months+1) LOOP
if i=1 then -- you should create the header
v_month := ' select to_char(add_months(to_date(:until_date,''dd/mm/yyyy''),' || TO_NUMBER (i-1)|| '),''' || c_rec.month_exp || ''') from dual';
EXECUTE IMMEDIATE v_month
INTO v1 using p_prod_until_month_include;
v_str_header := 'CREATE OR REPLACE VIEW '||c_rec.view_name||' AS '||chr(10);
v_str := v_str_header||' '||c_rec.view_text||v1||chr(10);
ub := ub + 1;
create_stmt (ub) := v_str;
else
v_month := ' select to_char(add_months(to_date(:until_date,''dd/mm/yyyy''), -'||to_number(i-1)||'),'''||c_rec.month_exp||''') from dual';
execute immediate v_month
into v1 using p_prod_until_month_include;
v_str := v_str ||'UNION ALL '||chr(10)||c_rec.view_text||v1||chr(10);
ub := ub + 1;
create_stmt (ub) := v_str;
end if;
end loop;
cursor_id := DBMS_SQL.open_cursor;
DBMS_SQL.parse (cursor_id, create_stmt, 1, ub, TRUE, DBMS_SQL.native);
ret_val := DBMS_SQL.EXECUTE (cursor_id);
dbms_output.put_line('View '||c_rec.view_name||' Created');
end loop;
ELSE -- v_instance_type HISTORY
FOR c_rec IN c (v_instance_type) LOOP
dbms_output.put_line('c_rec.hist_num_of_months='||c_rec.hist_num_of_months);
IF v_its_new_view = 'Y' THEN
v_its_new_view := 'N';
END IF;
FOR i IN 1 .. (c_rec.hist_num_of_months+1) LOOP
IF i = 1 THEN -- you should create the header
v_month := ' select to_char(add_months(:start_date,' || TO_NUMBER (i-1)|| '),''' || c_rec.month_exp || ''') from dual';
EXECUTE IMMEDIATE v_month
INTO v1 using c_rec.start_from;
v_str_header := 'CREATE OR REPLACE VIEW '|| c_rec.view_name || ' AS ' || CHR (10);
v_str := v_str_header || ' ' || c_rec.view_text || v1 || CHR (10);
ub := ub + 1;
create_stmt (ub) := v_str;
ELSE
v_month := ' select to_char(add_months(:start_date, '
|| TO_NUMBER (i-1 )
|| '),'''
|| c_rec.month_exp
|| ''') from dual';
EXECUTE IMMEDIATE v_month
INTO v1 using c_rec.start_from;
v_str := 'UNION ALL ' || CHR (10) || c_rec.view_text || v1 || CHR (10);
ub := ub + 1;
create_stmt (ub) := v_str;
END IF;
END LOOP;
IF NVL (c_rec.complex_view, 'N') = 'Y' THEN
v_str := 'UNION ALL ' || CHR (10) || c_rec.union_with || CHR (10);
ub := ub + 1;
create_stmt (ub) := v_str;
END IF;
v_its_new_view := 'Y';
cursor_id := DBMS_SQL.open_cursor;
DBMS_SQL.parse (cursor_id, create_stmt, 1, ub, TRUE, DBMS_SQL.native);
ret_val := DBMS_SQL.EXECUTE (cursor_id);
dbms_output.put_line('View '||c_rec.view_name||' Created');
END LOOP;
END IF;
END;user546852 wrote:
Hi,
I dont think its possible in case when the string is more that 32K.
ThanksIt is possible to create a SQL statement larger than 32K.
Firstly, you need take your statement (easiest if it's built up in a CLOB), the split it up into the DBMS_SQL.VARCHAR2S array structure (_not_ the VARCHAR2A structure), and then execute that as your statement.
Example:
SQL> ed
Wrote file afiedt.buf
1 declare
2 v_large_sql CLOB;
3 v_num NUMBER := 0;
4 v_upperbound NUMBER;
5 v_sql DBMS_SQL.VARCHAR2S;
6 v_cur INTEGER;
7 v_ret NUMBER;
8 begin
9 -- Build a very large SQL statement in the CLOB
10 LOOP
11 IF v_num = 0 THEN
12 v_large_sql := 'CREATE VIEW vw_tmp AS SELECT ''The number of this row is : '||to_char(v_num,'fm0999999')||''' as col1 FROM DUAL';
13 ELSE
14 v_large_sql := v_large_sql || ' UNION ALL SELECT ''The number of this row is : '||to_char(v_num,'fm0999999')||''' as col1 FROM DUAL';
15 END IF;
16 v_num := v_num + 1;
17 EXIT WHEN DBMS_LOB.GETLENGTH(v_large_sql) > 40000 OR v_num > 800;
18 END LOOP;
19 DBMS_OUTPUT.PUT_LINE('Length:'||DBMS_LOB.GETLENGTH(v_large_sql));
20 DBMS_OUTPUT.PUT_LINE('Num:'||v_num);
21 --
22 -- Now split that large SQL statement into chunks of 256 characters and put in VARCHAR2S array
23 v_upperbound := CEIL(DBMS_LOB.GETLENGTH(v_large_sql)/256);
24 FOR i IN 1..v_upperbound
25 LOOP
26 v_sql(i) := DBMS_LOB.SUBSTR(v_large_sql
27 ,256 -- amount
28 ,((i-1)*256)+1 -- offset
29 );
30 END LOOP;
31 --
32 -- Now parse and execute the SQL statement
33 v_cur := DBMS_SQL.OPEN_CURSOR;
34 DBMS_SQL.PARSE(v_cur, v_sql, 1, v_upperbound, FALSE, DBMS_SQL.NATIVE);
35 v_ret := DBMS_SQL.EXECUTE(v_cur);
36 DBMS_OUTPUT.PUT_LINE('View Created');
37* end;
SQL> /
Length:40015
Num:548
View Created
PL/SQL procedure successfully completed.
SQL> select count(*) from vw_tmp;
COUNT(*)
548
SQL> select * from vw_tmp where rownum <= 10;
COL1
The number of this row is : 0000000
The number of this row is : 0000001
The number of this row is : 0000002
The number of this row is : 0000003
The number of this row is : 0000004
The number of this row is : 0000005
The number of this row is : 0000006
The number of this row is : 0000007
The number of this row is : 0000008
The number of this row is : 0000009
10 rows selected.
SQL> -
Need to execute Long Insert (6000 characters)statement using dbms_sql.parse
I built an insert statement which is more than 6000 (six thousand) characters stored into two varchar2 variables. I need to execute the statement using dbms_sql.parse.
I tryed using dbms_sql.varchar2s variable and having no success.
Any ideas or examples?
Thanks
JK6000 chars shouldn't be a problem.
What do you mean with no success?Did you get any error?
Any ideas or examples?See this thread
Re: execute immediate with a string longer than 32767 -
APEX Insufficient Privs errors when trying to use dbms_sql.parse
Hello,
I have a simple database procedure that changes are user pswd:
create or replace
PROCEDURE chg_pswd_test(p_userid in varchar2,
p_pswd in varchar2)
-- Invoker rights allow a user with execute privileges to call a subprogram.
-- Definer Rights allow programs to execute under the privileges of their
-- definer / schema owner.
AUTHID CURRENT_USER as x varchar2(20);
v_cursor INTEGER;
v_execute INTEGER;
begin
v_cursor := sys.DBMS_SQL.OPEN_CURSOR;
sys.DBMS_SQL.PARSE(v_cursor, 'ALTER USER '||p_userid||' identified by '||p_pswd, sys.DBMS_SQL.NATIVE);
v_execute := sys.DBMS_SQL.EXECUTE(v_cursor);
sys.DBMS_SQL.CLOSE_CURSOR(v_cursor);
commit;
end chg_pswd_test;
I can run this procedure in sqlplus as user x and also as my apex_public_user. I have granted both execute on dbms_sql and alter user privs. It runs for both without problems.
I then create a validation process in APEX can call this database procedure. I then receive insufficient privs errors.
If I grant all privs to public, the apex app will then run, if I remove all privs I receive the errors again.
Does anyone know which database priv I am missing, I cannot grant all privs to public on my production database?
ThanksOdd, as I would think that should work, being the DBA role and all...
If it works as user X from SQL*Plus, could you try to change the parsing schema to User X and try again?
Thanks,
- Scott -
http://spendolini.blogspot.com
http://sumnertechnologies.com -
PLEASE HELP FAST :dbms_sql.parse, insufficient privileges
DBMS_SQL.PARSE statement
When Executed from a call within a package, I get the message insufficient privileges.
I tried executing it from the user-schema from the owner and from an other user.
When executed from within a sql-statement there is no problem.
Example:
DECLARE
p_sql_cursor number;
sql_statement varchar2(1000) := ;
BEGIN
sql_cursor := dbms_sql.open_cursor;
dbms_sql.parse(p_sql_cursor, sql_statement, 1);
END;
This is not a problem.
Does anyone know if this has something to do with access rights/grants.
If so, please tell me what access rights/grants I need to execute this statement succesfully from within a package
If not please let me know what you think is the problem and how I can fix it.
Thanks in advance,
please mail me, i don't know if i have time to check te discussion board<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by Jerry Cligge ([email protected]):
Thanks for your reply, but I need to know what priviliges i need to have to parse a create view statement!!!!!!!!!!!!!<HR></BLOCKQUOTE>
Dynamic sql looks only on directly granted privileges not via roles, for exampkle, resource
So try to grant create view to this user
null -
Tough Parsing question???
Please try to help me with the following parsing question.
I have an exert from the 2000 Tiger/Line Census files that looks
something like this:
0001 A Libby Ln -92.99999+25.87787 -92.87679+26.65543
0002 A Capri Ave -93.32343+23.3332 3 -24.34444+34.22222
0003 A Minster Grove Ln -93.23433+22.2223432 -98.343343+23.34332
0003 A Houston Ave -91.99892+22.323322 -98.434543+33.33233
0004 A I-10 Int -91.23234+32.343232 -97.333233+34.22222
0005 C Trenton Springs Ct. -90.22232+33.222123 -91.234432+23.33221
I want to parse it so I can enter it into an SQL database.
Normally this would be an easy task but, the file is not comma
deliminated. Usaully I could just break it apart at the white space
but as you can see above, some of the street names (the third column)
have whitespace in the text. I have almost declared it impossible
and am about to give up an buy prepackaged/parsable software.
I will feel very small if I have to do that.
Thanks for any help,
Ianpublic class CensusParser
String[] census = { "0001 A Libby Ln -92.99999+25.87787 -92.87679+26.65543",
"0002 A Capri Ave -93.32343+23.3332 3 -24.34444+34.22222",
"0003 A Minster Grove Ln -93.23433+22.2223432 -98.343343+23.34332",
"0003 A Houston Ave -91.99892+22.323322 -98.434543+33.33233",
"0004 A I-10 Int -91.23234+32.343232 -97.333233+34.22222",
"0005 C Trenton Springs Ct. -90.22232+33.222123 -91.234432+23.33221" };
int cur, flds;
String n = "";
void parse() {
for (int x=0; x<census.length; x++) {
flds = 0;
cur=census[x].length();
n = "";
for (int y=census[x].length()-1; y>=0 && flds < 4; y--) {
if (census[x].charAt(y) == '-' || census[x].charAt(y) == '+') {
n = "," + census[x].substring(y, cur).trim() + n;
cur = y;
flds++;
n = census[x].substring(0, cur).trim() + n;
census[x] = n;
System.out.println(n);
public static void main(String[] args) {
CensusParser cp = new CensusParser();
cp.parse();
}Not very efficient, but it works!
Mark
Maybe you are looking for
-
Are you "hoarding" contacts? It may be time to purge your database
I moved homes this month, which is a pretty excruciating process if you’ve not done it recently. Everyone with whom I’ve commiserated tells me this: If you have a packed box that you haven’t opened in six months or more after the move, just get rid o
-
How could i install Java on my Mac OS X 10.6.8 ?
Hello. First of all I am French so please excuse me for my English. I tried to install Java on my MAC but unfortunately the download of the software always meets the same problem... It asks me to be under mac OS X 10.7 but my computer does not propos
-
Photoshop CC 2014 can't handle huge file.
I have a 60mb photoshop file that I am opening. Photoshop CC is handling it fine. But photoshop CC 2014 is very slow when I turn on and off layers it takes about 2 seconds for the action for this specific file and on Photoshop CC its instantaneous,
-
Error in PC_PAYRESULT for : For Period Display
Hi Experts, Getting error in pc_payresult transaction. " No data exists for sequence number 00002". This error I am getting when I am executing two months payroll together. For period 05.2011 in period 06.2011 For period 06.2011 in period 06.2011 No
-
How to unlock my iphone if i forgot my password
i really need help