What's disadvantages when using bind variables always in java?

Hello everyone .. Could someone tell me what's the disadvantage when using bind variable in java ? I heard it somecases since before.. Thanks in advance!

99% of the time, you should be using bind variables. If you have columns which are highly skewed, however, you may want to consider using literals (assuming CURSOR_SHARING=EXACT), since that may allow the CBO to make a better decision.
If you have an orders table, for example, you may have a status column that specifies whether the order is complete, in transit, or new. If you've been running for a while, 99% of your orders will be complete, so
SELECT COUNT(*)
  FROM orders
WHERE status = :1should do a full table scan if you specify 'COMPLETE'. If you passed in 'IN TRANSIT', though, an index scan might be more appropriate. If you want to pass in different values and get different query plans, you need to use literals. 99% of the time, though, you want the same plan, so you want to use bind variables.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

Similar Messages

  • Query don't use the right index when using bind variables

    Hi people !
    I need some help because I have an issue with a query that don t use the right Indexes as it should
    First of all, I have mainly three tables :
    ORDER : Table that contains description for each Order (approximately 1 000 000 Records)
    ORDER_MVTS : Table that contains the tasks made (called movements) to set up each Orders
    with quantity of packages prepared for each product (approximately 10 000 000 Records)
    PRODUCT : Tables that contains the products (approximately 50 000 Records)
    When I launch the query with hard coded values, it brings back response very fast
    because it uses the right index (ORDER_DHR_VALID) which represent the date and hour of the order
    (with format 'DD/MM/YYYY HH24:MI:SS'). The selectivity for this index is good.
    NB 1: I have to use the trick " >= Trunc(date) and < trunc(date) +1 " to filter on a simple date because
    the index contains hour and minutes (I know it wasn't probably a bright idea at conception time).
    NB 2: The index on ORDER_MVTS.PRODUCT_CODE is'nt discriminating enough because there is'nt enough different products.
    It's the same for index on CUSTOMER_CODE and on MVT_TYPE so only the index on ORDER.DHR_VALID is good.
    Here is the correct explain plan when I execute the query with hard coded values :
    SELECT SUM(ORDER_MVTS.NB_PACKAGE)
    FROM ORDER_MVTS, PRODUCT, ORDER
    WHERE ORDER.DHR_VALID >= TRUNC(to_date('14/11/2008 10:04:56','DD/MM/YYYY HH24:MI:SS'))
    AND ORDER.DHR_VALID < TRUNC(to_date('14/11/2008 10:04:56','DD/MM/YYYY HH24:MI:SS')) + 1
    AND ORDER_MVTS.MVT_TYPE = 'DELIVERY'
    AND PRODUCT.CODE = ORDER_MVTS.PRODUCT_CODE
    AND ORDER_MVTS.ORDER_CODE = ORDER.CODE
    AND ORDER.CUSTOMER_CODE = 'ADIDAS'
    AND PRODUCT.CODE = 1234
    Rows Row Source Operation
    1 SORT AGGREGATE
    2 NESTED LOOPS
    4 NESTED LOOPS
    2 INDEX UNIQUE SCAN (object id 378548) --> PRODUCT_PK
    4 TABLE ACCESS BY INDEX ROWID ORDER
    777 INDEX RANGE SCAN (object id 378119) --> ORDER_DHR_VALID
    2 TABLE ACCESS BY INDEX ROWID ORDER_MVTS
    30 INDEX RANGE SCAN (object id 377784) --> ORDER_MVTS_ORDER_FK
    Now the problem is when the query is used in a Cursor with bind variables.
    It seems like Oracle don't use index on ORDER.DHR_VALID because he can't figure out that he have
    to actually filter on a short period of time (only one day).
    So Oracle uses the index on ORDER_MVTS.PRODUCT_CODE which is'nt a bright idea (it takes 10 secondes instead of just one)
    Here is the bad explain plan :
    Rows Row Source Operation
    1 SORT AGGREGATE
    2 NESTED LOOPS
    722 NESTED LOOPS
    2 INDEX UNIQUE SCAN (object id 378548) --> PRODUCT_PK
    722 TABLE ACCESS BY INDEX ROWID ORDER_MVTS
    1790 INDEX RANGE SCAN (object id 377777) --> ORDER_MVTS_PRODUCT_FK
    2 TABLE ACCESS BY INDEX ROWID ORDER
    1442 INDEX UNIQUE SCAN (object id 378439) --> ORDER_PK
    Now I have found two solutions to this problem :
    1) using a Hint to force the use of index on ORDER.DHR_VALID (with /*+ INDEX(ORDER ORDER_DHR_VALID) */ )
    2) Using Dynamic SQL and keeping the date hard coded (but not the other values except mvt_type)
    For example :
    QUERY :=
    'SELECT SUM(ORDER_MVTS.NB_PACKAGE)
    FROM ORDER_MVTS, PRODUCT, ORDER
    WHERE ORDER.DHR_VALID >= TRUNC(TO_DATE('''||To_char(P_DTE_VAL,'DD/MM/YYYY')||''',''DD/MM/YYYY'')) '||
    AND ORDER.DHR_VALID < TRUNC(TO_DATE('''||To_char(P_DTE_VAL,'DD/MM/YYYY')||''',''DD/MM/YYYY'')) + 1 '||
    AND ORDER_MVTS.MVT_TYPE = 'DELIVERY'
    AND PRODUCT.CODE = ORDER_MVTS.PRODUCT_CODE
    AND ORDER_MVTS.ORDER_CODE = ORDER.CODE
    AND ORDER.CUSTOMER_CODE = :CUSTOMER
    AND PRODUCT.CODE = :CODE ';
    These two solutions work but Number 1 is bad in theory because it uses a Hint
    and Number 2 may be difficult to code.
    So my question is : Does someone knows another solution to force the use of index ORDER_DHR_VALID that can be simple and reliable.
    Thank you very much for support
    Edited by: remaï on Apr 1, 2009 4:08 PM

    What version of oracle you have? CBO work is different in 9i and 10g.
    Usually cost based optimizer do not want to use index for >< condition with binding variables because optimizer can not use statistic to determine selectivity, and by default selectivity of <> operators is low.
    (As I remember '>' selectivity by default is 5%, you have two conditions > and <, therefore resulting selectivity will be 0.05*0.05=0.0025 as two independent events, but selectivity of other conditions
    ORDER_MVTS.MVT_TYPE = 'DELIVERY' or ORDER.CUSTOMER_CODE = 'ADIDAS' looks much better for CBO)
    The best solution I see is do not use binding variables. Actually your query looks as searching query, which executes not so often, therefore you will not have perfomance win along of skipping execution plan creation.
    Edited by: JustasVred on Apr 1, 2009 10:10 AM

  • Query taking too long when using bind variable

    Hi All,
    There is a query in our prod DB which runs very slow (approx 2 hours) when it uses Bind Variables (using JDBC thin client), and when i try passing the variable using TOAD/SQL developer it runs fine.
    Explain Plan for running Query
    SELECT STATEMENT ALL_ROWSCost: 146 Bytes: 379 Cardinality: 1                                                   
         21 SORT ORDER BY Cost: 146 Bytes: 379 Cardinality: 1                                              
              20 NESTED LOOPS Cost: 145 Bytes: 379 Cardinality: 1                                         
                   17 HASH JOIN Cost: 22 Bytes: 42,558 Cardinality: 123                                    
                        15 MERGE JOIN CARTESIAN Cost: 15 Bytes: 8,910 Cardinality: 27                               
                             12 FILTER                          
                                  11 NESTED LOOPS OUTER Cost: 9 Bytes: 316 Cardinality: 1                     
                                       8 NESTED LOOPS OUTER Cost: 8 Bytes: 290 Cardinality: 1                
                                            5 NESTED LOOPS Cost: 6 Bytes: 256 Cardinality: 1           
                                                 2 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE GDP.GDP_FX_DEALS_INCREMENTOR Cost: 4 Bytes: 28 Cardinality: 1 Partition #: 9 Partition access computed by row location     
                                                      1 INDEX RANGE SCAN INDEX GDP.GDP_FX_DEALS_INC_IDX_01 Cost: 3 Cardinality: 1
                                                 4 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_FX_DEALS Cost: 2 Bytes: 228 Cardinality: 1      
                                                      3 INDEX UNIQUE SCAN INDEX (UNIQUE) GDP.GDP_FX_DEALS_KEY Cost: 1 Cardinality: 1
                                            7 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_FX_DEALS Cost: 2 Bytes: 34 Cardinality: 1           
                                                 6 INDEX UNIQUE SCAN INDEX (UNIQUE) GDP.GDP_FX_DEALS_KEY Cost: 1 Cardinality: 1      
                                       10 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_COUNTERPARTIES Cost: 1 Bytes: 26 Cardinality: 1                
                                            9 INDEX UNIQUE SCAN INDEX (UNIQUE) GDP.PK_CPTY Cost: 0 Cardinality: 1           
                             14 BUFFER SORT Cost: 14 Bytes: 448 Cardinality: 32                          
                                  13 TABLE ACCESS FULL TABLE GDP.GDP_CITIES Cost: 6 Bytes: 448 Cardinality: 32                     
                        16 TABLE ACCESS FULL TABLE GDP.GDP_AREAS Cost: 6 Bytes: 2,304 Cardinality: 144                               
                   19 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_PORTFOLIOS Cost: 1 Bytes: 33 Cardinality: 1                                    
                        18 INDEX UNIQUE SCAN INDEX (UNIQUE) GDP.PORTFOLIOS_KEY Cost: 0 Cardinality: 1                               
    Explain Plan for Slow Query
    Plan
    SELECT STATEMENT ALL_ROWSCost: 11,526,226 Bytes: 119,281,912 Cardinality: 314,728                                                   
         21 SORT ORDER BY Cost: 11,526,226 Bytes: 119,281,912 Cardinality: 314,728                                              
              20 HASH JOIN Cost: 11,510,350 Bytes: 119,281,912 Cardinality: 314,728                                         
                   2 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_PORTFOLIOS Cost: 1,741 Bytes: 177,540 Cardinality: 5,380                                    
                        1 INDEX FULL SCAN INDEX (UNIQUE) GDP.PORTFOLIOS_KEY Cost: 14 Cardinality: 5,380                               
                   19 HASH JOIN Cost: 11,507,479 Bytes: 87,932,495,360 Cardinality: 254,140,160                                    
                        3 TABLE ACCESS FULL TABLE GDP.GDP_AREAS Cost: 6 Bytes: 2,304 Cardinality: 144                               
                        18 MERGE JOIN CARTESIAN Cost: 11,506,343 Bytes: 18,602,733,930 Cardinality: 56,371,921                               
                             15 FILTER                          
                                  14 HASH JOIN RIGHT OUTER Cost: 3,930,405 Bytes: 556,672,868 Cardinality: 1,761,623                     
                                       5 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_COUNTERPARTIES Cost: 6,763 Bytes: 892,580 Cardinality: 34,330                
                                            4 INDEX FULL SCAN INDEX (UNIQUE) GDP.PK_CPTY Cost: 63 Cardinality: 34,330           
                                       13 HASH JOIN OUTER Cost: 3,923,634 Bytes: 510,870,670 Cardinality: 1,761,623                
                                            10 HASH JOIN Cost: 2,096,894 Bytes: 450,975,488 Cardinality: 1,761,623           
                                                 7 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE GDP.GDP_FX_DEALS_INCREMENTOR Cost: 2,763 Bytes: 52,083,248 Cardinality: 1,860,116 Partition #: 14 Partition access computed by row location     
                                                      6 INDEX RANGE SCAN INDEX GDP.GDP_FX_DEALS_INC_IDX_01 Cost: 480 Cardinality: 334,821
                                                 9 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_FX_DEALS Cost: 1,734,205 Bytes: 8,320,076,820 Cardinality: 36,491,565      
                                                      8 INDEX FULL SCAN INDEX (UNIQUE) GDP.GDP_FX_DEALS_KEY Cost: 104,335 Cardinality: 39,200,838
                                            12 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_FX_DEALS Cost: 1,733,836 Bytes: 1,331,145,696 Cardinality: 39,151,344           
                                                 11 INDEX FULL SCAN INDEX (UNIQUE) GDP.GDP_FX_DEALS_KEY Cost: 104,335 Cardinality: 39,200,838      
                             17 BUFFER SORT Cost: 11,499,580 Bytes: 448 Cardinality: 32                          
                                  16 TABLE ACCESS FULL TABLE GDP.GDP_CITIES Cost: 4 Bytes: 448 Cardinality: 32                     
    How can I avoid that.
    Thanks

    Hello
    Could you reformat your execution plans because they aren't particularly readable. The forums allow you to preserve the formatting of code or output by putting the symbol {noformat}{noformat} before and after the section of text you want to preserve formatting for. 
    If you write
    {noformat}select * from v$version
    {noformat}
    it will be displayed asselect * from v$version
    So can you run this above statement and post the output here so we know the full oracle version you are working with?  And finally, it would be really helpful to see the query you are running.  When you say it runs fine in Toad, is that when you replace the bind variables with the values or are you also using bind variables in Toad?
    Cheers
    David                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

  • Possible for Oracle to consider constraints when using bind variable?

    Consider the following table with a check constraint listing the possible values of the column
    create table TEST_TABLE(
    my_column varchar2(10));
    insert into TEST_TABLE select 'VALUE1' from dba_objects;
    alter table TEST_TABLE
    add constraint TEST_TABLE_CHK1
    check (my_column in ('VALUE1', 'VALUE2'));
    begin dbms_stats.gather_table_stats(ownname=>user,tabname=>'TEST_TABLE');END;Let's see the number of logical I/O's needed for the following SQL statements.
    (The value was obtained by the delta ofselect m.value from v$mystat m, v$statname n
    where name='session logical reads' and m.statistic#=n.statistic#)
    If string lateral is used:
    declare
       n number;
    begin
      select count(*) into n from test_table where my_column='VALUE1';
    end;
    Consistent Gets: 21
    declare
       n number;
    begin
      select count(*) into n from test_table where my_column='VALUE2';
    end;
    Consistent Gets: 21
    declare
       n number;
    begin
      select count(*) into n from test_table where my_column='VALUE3';
    end;
    Consistent Gets: 0Oracle can eliminate the table if it knows the queried value can't satisfy the constraint. Good.
    (Actually, the execution plan for the last query included the 'FILTER' operation.)
    However, if bind variable is used:
    declare
       n number;
       x varchar2(10);
    begin
      x := 'VALUE1';
      select count(*) into n from test_table where my_column=x;
    end;
    Consistent Gets: 21
    declare
       n number;
       x varchar2(10);
    begin
      x := 'VALUE3';
      select count(*) into n from test_table where my_column=x;
    end;
    Consistent Gets: 21Oracle can't eliminate the table using the constraint. I can understand that because bind variables are used, Oracle can't directly eliminate the table when generating the execution plan. However, is it possible to eliminate the table, or at least employ some shortcut in runtime? If not, will this be a performance loss compared with using values laterals when check constraint exists?
    (And is it possible to use autotrace on PL/SQL block in sqlplus?)
    Oracle:
         10.2.0.4 SE
         11.2.0.2 SE
    OS:
         RHEL5

    However, is it possible to eliminate the table, or at least employ some shortcut in runtime? I can't see how to do this. Oracle has a sqltext that has an embedded bind variable in it. And for this sqltext it has an execution plan in the shared pool that will be used irrespective of the actual bound values at runtime.
    Maybe in 11G, with adaptive cursor sharing / plan bind awareness, Oracle might be smart enough to introduce a second execution plan for the VALUE3 case.
    If not, will this be a performance loss compared with using values laterals when check constraint exists?Only if you submit the dumb query and search for records with VALUE3... Normally your application code would not hold/generate these queries.
    Will it?
    For columns whose values are bound by a CHECK constraint, one might even consider to never use bind variables, since very likely you will have few versions of queries that use these columns.
    Not?
    Edited by: Toon Koppelaars on Jun 22, 2011 1:20 PM

  • Csv no data found when using bind variables

    Hi,
    I have created a report, that uses 2 date variables to limit the query and rows display as they should. But clicking the csv link opens csv having one row stating 'No data found...'. If I set static values in place of variables, I get the right result. How could I use bind variables and get the right answer in csv (without coding my own function)?
    Kaja

    I am having the same problem.
    The export link opens a new session without submitting the current page. The page item values are therefor not saved to cache before the export is undertaken.
    Any report using page item bind variables in the where clause will not export correctly as the bind values are either null or those of the previous page submit.
    Any ideas on how to get round this??

  • Performance when using bind variables

    I'm trying to show myself that bind variables improve performance (I believe it, I just want to see it).
    I've created a simple table of 100,000 records each row a single column of type integer. I populate it with a number between 1 and 100,000
    Now, with a JAVA program I delete 2,000 of the records by performing a loop and using the loop counter in my where predicate.
    My first JAVA program runs without using bind variables as follows:
    loop
    stmt.executeUpdate("delete from nobind_test where id = " + i);
    end loop
    My second JAVA program uses bind variables as follows:
    pstmt = conn.prepareStatement("delete from bind_test where id = ?");
    loop
    pstmt.setString(1, String.valueof(i));
    rs = pstmt.executeQuery();
    end loop;
    Monitoring of v$SQL shows that program one doesn't use bind variables, and program two does use bind variables.
    The trouble is that the program that does not use bind variables runs faster than the bind variable program.
    Can anyone tell me why this would be? Is my test too simple?
    Thanks.

    [email protected] wrote:
    I'm trying to show myself that bind variables improve performance (I believe it, I just want to see it).
    I've created a simple table of 100,000 records each row a single column of type integer. I populate it with a number between 1 and 100,000
    Now, with a JAVA program I delete 2,000 of the records by performing a loop and using the loop counter in my where predicate.
    Monitoring of v$SQL shows that program one doesn't use bind variables, and program two does use bind variables.
    The trouble is that the program that does not use bind variables runs faster than the bind variable program.
    Can anyone tell me why this would be? Is my test too simple?
    The point is that you have to find out where your test is spending most of the time.
    If you've just populated a table with 100,000 records and then start to delete randomly 2,000 of them, the database has to perform a full table scan for each of the records to be deleted.
    So probably most of the time is spent scanning the table over and over again, although most of blocks might already be in your database buffer cache.
    The difference between the hard parse and the soft parse of such a simple statement might be negligible compared to effort it takes to fulfill each delete execution.
    You might want to change the setup of your test: Add a primary key constraint to your test table and delete the rows using this primary key as predicate. Then the time it takes to locate the row to delete should be negligible compared to the hard parse / soft parse difference.
    You probably need to increase your iteration count because deleting 2,000 records this way probably takes too short and introduces measuring issues. Try to delete more rows, then you should be able to spot a significant and constant difference between the two approaches.
    In order to prevent any performance issues from a potentially degenerated index due to numerous DML activities, you could also just change your test case to query for a particular column of the row corresponding to your predicate rather than deleting it.
    Regards,
    Randolf
    Oracle related stuff blog:
    http://oracle-randolf.blogspot.com/
    SQLTools++ for Oracle (Open source Oracle GUI for Windows):
    http://www.sqltools-plusplus.org:7676/
    http://sourceforge.net/projects/sqlt-pp/

  • Poor performance when using bind variable in report

    I have a report that takes 1 second to run if i 'hardcode' a particular value into the where clause of the report. However, if i now replace the hardcoded value with a bind variable and set the default value for the bind variable to be the (previous) hard coded value the report now takes 50 seconds to run instead of 1 second!!
    Has anyone else seen this behaviour - any suggestions to workaround this will be gratefully received

    More info
    SELECT patch_no, count(*) frequency
    FROM users_requests
    WHERE patchset IN (SELECT arps2.patchset_name
    FROM aru_bugfix_relationships abr, aru_bugfixes ab, aru_status_codes ac,
    aru_patchsets arps, aru_patchsets arps2
    WHERE arps.patchset_name = '11i.FIN_PF.E'
    AND abr.bugfix_id = ab.bugfix_id
    AND arps.bugfix_id = ab.bugfix_id
    AND abr.relation_type = ac.status_id
    AND arps2.bugfix_id = abr.related_bugfix_id
    AND abr.relation_type IN (601, 602))
    AND included ='Y'
    GROUP BY patch_no
    order by frequency desc, patch_no
    Runs < 1 sec from SQL navigator and from portal (if i hardcode the value for fampack.
    Takes ~50 secs if i replace with :fampack and set default value to 11i.FIN_PF.D

  • Correct Way to use Bind variables when using an MS SQL server backend

    Hey,
    I'm having some trouble figuring out how to use bind variables in a view when using an MS SQL server backend. For some reason when I'm using an ApplicationModule that has a MS SQL Server JDBC library loaded and I attempt to click OK when editing the following query:
    SELECT kit_status, component_id
    FROM numbered_inv
    WHERE trialname = :1
    I get an error stating that "SQL Query Error Message Incorrect Syntax near ':'". Is JDeveloper compatible with SQL server for bind variables because this query runs just fine if I replace the :1 with a say "Testing testing".
    Thanks in advance
    Edited by: NullCheck on Dec 15, 2010 2:06 PM

    Gotcha. I had tried %1% %0% ?0 and ?1 and various other permutations none of which worked. Got it working by setting the query to:
    SELECT kit_status, component_id
    FROM numbered_inv
    WHERE trialname = ?
    ORDER BY kit_status
    And then adding a bind variable with "Bind position" set to 0.
    Thanks again Shay!

  • What can i replace this bind variable with in function?

    Hello
    I am creating a report showing training attended by employees. I have written a function to do the following:
    Parameters 1 - 4 is hard coded for a reason. So we dont worry about them.
    5th parameter: :START_DATE represents the date training started
    6th parameter: :END_DATE represents the date training ended.
    These date parameters are correctly used inside the select statement that the function is built upon. So don't worry that my date parameters are correct/incorrect.
    The focus should be on how you use bind variables inside Discoverer Admin. The select at the bottom runs perfectly in Toad and it allows you to use the date parameters as bind variables. But it does not allow it in Discoverer Admin
    The problem is with Parameter 5 and 6. I dont want to hard code the dates as i want the user to be able to enter his own date parameters.
    Discoverer Admin gives an error is i want to use :START_DATE and :END_DATE as parameters
    Does anyone have a solution for my problem.
    This is what the code looks like.
    SELECT apps.xxhr_fsc_training_info.xxhr_fsc_training ('A', '02','M', 'N',:START_DATE, :END_DATE)category_A_training
    , apps.xxhr_fsc_training_info.xxhr_fsc_training ('B', '02','M', 'N',:START_DATE, :END_DATE)category_B_training
    , apps.xxhr_fsc_training_info.xxhr_fsc_training ('C', '02','M', 'N',:START_DATE, :END_DATE)category_C_training
    , apps.xxhr_fsc_training_info.xxhr_fsc_training ('D', '02','M', 'N',:START_DATE, :END_DATE)category_D_training
    , apps.xxhr_fsc_training_info.xxhr_fsc_training ('E', '02','M', 'N',:START_DATE, :END_DATE)category_E_training
    , apps.xxhr_fsc_training_info.xxhr_fsc_training ('F', '02','M', 'N',:START_DATE, :END_DATE)category_F_training
    , apps.xxhr_fsc_training_info.xxhr_fsc_training ('G', '02','M', 'N',:START_DATE, :END_DATE)category_G_training
    from dual
    Edited by: iandekoker on Jun 8, 2009 9:34 PM

    Rod
    I have a request. The request is based on various emails written about passing parameters in Discoverer Admin/Desktop. Now if you are experienced and work with set copntext on regular basis then it should be a walk in the park. However if you are new to it like me, then it seems a daunting task. So my request is: Can't you provide us with an example of how to complete the whole process from begin to end using an actual example? I will kick off the process and maybe you can add where i left something out?
    Example:
    SELECT ENAME, HIRE_DATE
    FROM EMP
    WHERE HIRE_DATE = :IDATE;
    We want to run this select statement in Discoverer Admin, but Admin does not like the :IDATE bind variable. So now we are gonna use SET CONTEXT to find a solution to our problem.
    Step1:
    First we have to create a context namespace in the database for the Discoverer contexts. Here is the code to create the context. It is okay to also named your function EUL_DISCO as this name would work perfectly for almost everyone. Best is to do all of this in the Apps schema. Copy and paste this code in Toad and F9 it. It should compile successfully
    CREATE OR REPLACE CONTEXT eul_disco
    USING apps.eul_disco;
    Step 2:
    Now you need to create a package to enable you to set and retrieve contexts from in Discoverer. Here is the code to create the package and package body. Just copy and paste the code into Toad and F9 (execute) it to create the package.
    --Package Spec
    CREATE OR REPLACE PACKAGE eul_disco AS
    FUNCTION set_context(p_name VARCHAR2, p_value VARCHAR2) RETURN VARCHAR2;
    FUNCTION show_context(p_name VARCHAR2) RETURN VARCHAR2;
    END eul_disco;
    --Package Body
    CREATE OR REPLACE PACKAGE BODY eul_disco IS
    FUNCTION set_context(p_name VARCHAR2, p_value VARCHAR2)
    RETURN VARCHAR2 AS
    BEGIN
    dbms_session.set_context('EUL_DISCO', p_name, p_value);
    RETURN p_value;
    END set_context;
    FUNCTION show_context(p_name VARCHAR2)
    RETURN VARCHAR2 IS
    BEGIN
    RETURN SYS_CONTEXT('EUL_DISCO', p_name);
    END show_context;
    END eul_disco;
    Step3:
    Once you have created this package successfully you need to log into Discoverer Admin. Then use the menu to navigate to Tools > Register PL/SQL Function. A window called 'PL/SQL Functions' will appear. Select the 'Import...' button. A new window called 'Import PL/SQL functions' will appear. Scroll down until you see set_context function. Once you found it click OK to import it to End User Layer. Do the same to import show_context function. Remember there are two functions and you need to import them both. When you are done, click 'Apply' button. Then click 'OK' button. You can double check to make sure your functions have been imported. Just nagivate to Tools > Register PL/SQL function again. When the window 'PL/SQL Functions' appears your function(s) should be in the list on the left hand site. Scroll down untill you find them.
    Step4:
    Now it is time to set your session parameters in a separate worksheet inside Discovere Desktop from your main reports. The following steps show you how to create a worksheet to define an effective date parameter. The parameter worksheet should be based on a folder that always returns exactly one row.
    Log into Discoverer Admin. Open the Business Area you want to use. Then create "New Custom Folder..."
    Copy and paste this code (select sydate from dual) inside the New Custom Folder and validate the code. Also rename your folder to 'Set Context Folder'
    Step 5
    Next log into Discoverer Desktop and choose 'Create New Workbook'. Then choose table layout option. In the available list choose 'Set Context Folder'. When you have highlighted 'Set Context Folder' click on '>' button. Then click then 'Finish' button. Once the workbook is created you will see 1 column called Sysdate and a row with today's date in it. Save this workbook and name this workbook XYZ. You might even rename the sheet to QWE.
    Step 6:
    Still in Desktop working on XYZ workbook on QWE sheet, click on Tools > Parameters > New. In the 'Name' field enter START_DATE. Next leave 'Create condition with operator' box unticked. Next in 'Prompt' field enter START_DATE. In 'Description' field enter START_DATE. In 'Default' field enter NULL. Click OK button when you are done.
    Step 7:
    Still in Desktop working on XYZ workbook on QWE sheet, click on Tools > Calculation > New. Click on 'Functions' radio button. Then click on 'Database' folder to expand it. Scroll down till you see 'Set Context' function in the list. Select it and click 'paste >>' button. It will now show: SET_CONTEXT(P_NAME, P_VALUE). Now you need to replace the two parameters (P_NAME, P_VALUE) of the function. Replace P_NAME with 'START_DATE'. When you are done click on Items radio button. Then click on the Parameters folder and select Start_Date.
    When you are done it should look like this: SET_CONTEXT('START_DATE',TO_CHAR(:START_DATE))
    You might want to rename this calculation to START_DATE
    Ps. If you need to create two date parameters START_DATE and END_DATE then you repeat step 7 cause you need one more calculation.
    Just replace START_DATE with END_DATE. You also might want to call this second calculation END_DATE. Thus when you are done you will have 2 calculations:
    SET_CONTEXT('START_DATE',TO_CHAR(:START_DATE))
    SET_CONTEXT('END_DATE',TO_CHAR(:END_DATE))
    This is useful when you want date parameters similar to: 'where date between :Start_date and :End_date'
    Step 8:
    When you now run the XYZ workbook (QWE sheet) it will prompt you for an START_DATE. Enter 10-Jun-2009 (make sure the format you enter the date is similar to the format you have set up in discoverer). Now your XYZ workbook have 2 columns. First column is still called Sysdate with today's date. The second column is called START_DATE with 10-JUN-2009 in it.
    Step 9:
    Now you want to remove the 'SELECT SYSDATE FROM DUAL' data stored in 'SET CONTEXT FOLDER' from your XYZ workbook (QWE sheet) as you no longer need that. Still working with Desktop inside XYZ workbook on QWE sheet > click on Sheet menu option > then Edit Sheet option. On the Select Items tab click on 'Set Context Folder' and click < button to remove the folder from workbook XYZ. Click OK when done and run the workbook XYZ (sheet QWE) again. Now the workbook XYZ (sheet QWE) should only have one column called START_DATE and 10-Jun-2009 as the only row.
    Step 10:
    Rob you might want to come in here. It is also useful to create another calculation retrieving the value of the parameter, so that the value entered for the parameter can be seen when the workbook is run. Please give step by step instruction to complete this process
    Step 11:
    Still remember your initial problem where we wanted to use :IDATE in Discoverer Admin folder, but Discoverer Admin did not like the :IDATE syntax?
    SELECT ENAME, HIRE_DATE
    FROM EMP
    WHERE HIRE_DATE = :IDATE;
    Solution:
    Well now you just replace :IDATE with TO_DATE(SYS_CONTEXT('EUL_DISCO','START_DATE'))
    Log into Discoverer Admin. Open your Business Area. Then create 'New Custom Folder..'.
    Copy the code below and paste it into the new custom folder.
    Then validate the code.
    Rename the new custom folder to 'Solution'
    --copy and paste this code into folder 'Solution'
    SELECT ENAME, HIRE_DATE
    FROM EMP
    WHERE HIRE_DATE = TO_DATE(SYS_CONTEXT('EUL_DISCO','START_DATE'))
    note: 'EUL_DISCO' is the name of the context and package you created in step1
    : 'START_DATE' is the name of the calculation you did in step7
    Then log onto Discoverer Desktop > open your workbook XYZ > open sheet QWE.
    Click on Menu item called Sheet > New Sheet > choose Table layout > click next > scroll down available folders till you find SQL folder with then name 'Solution'. Select 'Solution' folder and click > then click Finish.
    The folder named 'Solution' will be used to populate the newly created sheet with data. You might want to rename the newly created sheet to 'Finally'.
    At this point workbook XYZ should have 2 sheets (QWE and Finally).
    Sheet 'QWE' contains the parameter and nothing else.
    Sheet 'Finally' displays the code found in folder 'Solution'
    First you run sheet QWE to set parameter. When prompt for a date enter '10-JUN-2009'. Click OK button.
    Then click on sheet 'Finally' to allow the parameter to take effect and do its job. You will see that only data true of 10-JUN-2009 are displayed
    Notes:
    This is a very simple example. But if you work thru this example, then you will get the concept behind the idea and would you be able to satisfy your own need.

  • Using Bind Variable in a SELECT

    Hi,
    I'm trying to build up my SQL query at run-time using bind variables and in the Oracle® Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework 11g Release 1 (11.1.1) it says that 'After defining the bind variables, the next step is to reference them in the SQL statement. While SQL syntax allows bind variables to appear both in the SELECT list and in the WHERE clause, you'll typically use them in the latter context, as part of your WHERE clause.'.
    However, when I try to use the bind variables in my SELECT list because I've had to set a type for the variable to String the variable gets inserted with inverted commas either side e.g. SELECT 'Service' FROM TestTable. Is it possible to use bind variables to insert a value into my select list without these inverted commas around it?
    Thanks in advance,
    Tom

    OK, thanks for your response. Do you know of a way then where I can control my SELECT parameters programmatically? I'm currently trying to do it using the information in the chapter '35.9 Using Programmatic View Objects for Alternative Data Sources' from the Oracle® Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework 11g Release 1 (11.1.1). I think I'm part way there, would this be the correct way of acheiving what I want?
    Cheers, Tom

  • Trying to pass array to stored procedure in a loop using bind variable

    All,
    I'm having trouble figuring out if I can do the following:
    I have a stored procedure as follows:
    create procedure enque_f826_utility_q (inpayload IN f826_utility_payload, msgid out RAW) is
    enqopt dbms_aq.enqueue_options_t;
    mprop dbms_aq.message_properties_t;
    begin
    dbms_aq.enqueue(queue_name=>'f826_utility_queue',
    enqueue_options=>enqopt,
    message_properties=>mprop,
    payload=>inpayload,
    msgid=>msgid);
    end;
    The above compiles cleanly.
    The first parameter "inpayload" a database type something like the following:
    create or replace type f826_utility_payload as object
    2 (
    3 YEAR NUMBER(4,0),
    4 MONTH NUMBER(2,0),
    83 MUSTHAVE CHAR(1)
    84 );
    I'd like to call the stored procedure enque_f826_utility_q in a loop passing to it
    each time, new values in the inpayload parameter.
    My questions are:
    First, I'm not sure in php, how to construct the first parameter which is a database type.
    Can I just make an associative array variable with the keys of the array the same as the columns of the database type shown above and then pass that array to the stored procedure?
    Second, is it possible to parse a statement that calls the enque_f826_utility_q procedure using bind variables and then execute the call to the stored procedure in a loop passing new bind variables each time?
    I've tried something like the following but it's not working:
    $conn = oci_pconnect (....);
    $stmt = "select * from f826_utility";
    $stid = oci_parse($conn, $sqlstmt);
    $r = oci_execute($stid, OCI_DEFAULT);
    $row = array();
    $msgid = "";
    $enqstmt = "call enque_f826_utility_q(:RID,:MID)";
    $enqstid = oci_parse($conn, $sqlstmt);
    oci_bind_by_name($enqstid, ":RID", $row); /* line 57 */
    oci_bind_by_name($enqstid, ":MID", $msgid);
    while ($row = oci_fetch_array($stid, OCI_RETURN_NULLS+OCI_ASSOC))
    ++$rowcnt;
    if (! oci_execute($enqstid)) /* line 65 */
    echo "Error";
    exit;
    When I run this, I get the following:
    PHP Notice: Array to string conversion in C:\Temp\enqueue_f826_utility.php on l
    ine 57
    Entering loop to process records from F826_UTIITY table
    PHP Notice: Array to string conversion in C:\Temp\enqueue_f826_utility.php on l
    ine 65
    PHP Warning: oci_execute(): ORA-06553: PLS-306: wrong number or types of argume
    nts in call to 'ENQUE_F826_UTILITY_Q' in C:\Temp\enqueue_f826_utility.php on lin
    e 65
    PHP Notice: Undefined variable: msgnum in C:\Temp\enqueue_f826_utility.php on l
    ine 68
    Error during oci_execute of statement select * from F826_UTILITY
    Exiting!

    Thanks for the reply.
    I took a look at this article. What it appears to describe is
    a calling a stored procedure that takes a collection type which is an array.
    Does anyone from Oracle know if I can pass other database type definitions to a stored procedure from PHP?
    I have a type defined in my database similar to the following which is not
    an array but a record of various fields. This type corresponds to a payload
    of an advanced queue payload type. I have a stored procedure which will take as it's input, a payload type of this structure and then enqueue it to a queue.
    So I want to be able to pass a database type similar to the following type definition from within PHP. Can anyone from Oracle verify whether or not this is possible?
    create or replace type f826_utility_payload as object
    YEAR NUMBER(4,0),
    MONTH NUMBER(2,0),
    UTILITY_ID NUMBER(10,0),
    SUBMIT_FAIL_BY VARCHAR2(30),
    MUSTHAVE CHAR(1)
    );

  • How to use bind variables in this procedure

    Hi Experts,
    How to use bind variables in this procedure for static queries.
    PROCEDURE DELETE_MER_PROC (M_id IN NUMBER)
    IS
    BEGIN
    V_date DATE;
    SELECT PD_DATE INTO v_date FROM PD_MAINTAIN;
        DELETE FROM MER_CLEAR
        WHERE MER_DT < v_date
        AND ID = M_ID;
    COMMIT;
    END;   
    How to use  v_date and m_id as bind variables in this procedure to avoid hard parsing.
    Please help me.
    Thanks.

    976208 wrote:
    How to use  v_date and m_id as bind variables in this procedure to avoid hard parsing.
    You cannot avoid hard parsing - as the 1st time a SQL statement (like the SELECT or DELETE statements in your code) is encountered, it does not reside in the server's Shared Pool, and needs to be added into the pool via a hard parse.
    Bind variables does not prevent hard parsing. Hard parsing happens when the SQL statement (with or without bind variables) is a brand new statement encountered by the server.
    Bind variables enables the same SQL cursor to be reused, by simply changing the bind variable value.
    Not using bind variables means that each SQL statement is unique and not shareable - as the value is hardcoded into the statement and cannot be changed via a bind value. This typically means LOTS of different SQL statements (where the only difference is the changed value in the statement) are created - with each statement being a new statement not seen before in the Shared Pool and needing to be hard parsed.
    One does not design one's code not to be hard parsed. There ALWAYS will be a hard parse in order to get a SQL statement into the Shared Pool. One designs one's code to REUSE cursors in the Shared Pool.

  • How to use bind variables in desc flexfields in OA pages?

    Use case: In EBS 11i we have a DFF on po_vendors and one of the segment has a table validated value set that is referencing a forms variable i.e :VENDORS.VENDOR_ID. Now after upgrading to R12 this won't work as the vendor pages moved to OA framework. Is there any way to reference the vendor_id column in OA framework?

    976208 wrote:
    How to use  v_date and m_id as bind variables in this procedure to avoid hard parsing.
    You cannot avoid hard parsing - as the 1st time a SQL statement (like the SELECT or DELETE statements in your code) is encountered, it does not reside in the server's Shared Pool, and needs to be added into the pool via a hard parse.
    Bind variables does not prevent hard parsing. Hard parsing happens when the SQL statement (with or without bind variables) is a brand new statement encountered by the server.
    Bind variables enables the same SQL cursor to be reused, by simply changing the bind variable value.
    Not using bind variables means that each SQL statement is unique and not shareable - as the value is hardcoded into the statement and cannot be changed via a bind value. This typically means LOTS of different SQL statements (where the only difference is the changed value in the statement) are created - with each statement being a new statement not seen before in the Shared Pool and needing to be hard parsed.
    One does not design one's code not to be hard parsed. There ALWAYS will be a hard parse in order to get a SQL statement into the Shared Pool. One designs one's code to REUSE cursors in the Shared Pool.

  • BUG ? :  ADF creating extra VO instance using bind variables in a LOV query

    ADF 11.1.1.1.0
    After "playing around" with bind variables Setting bind variables in view objects for LOV I've come across something strange that I've reproduce using the HR schema and tables Employees and Departments. Its a bit long but here goes :
    Using the HR schema tables departments and employeesI'm trying to create a LOV (selectOneChoice) for the
    employee department, the LOV having a bind variable that limits the values returned in this case returning only DepartmentId = 50
    I've create a VO lovDepartment (not based on an EO) with the following query :
    SELECT Departments.DEPARTMENT_ID,
           Departments.DEPARTMENT_NAME,
           Departments.MANAGER_ID,
           Departments.LOCATION_ID
    FROM DEPARTMENTS Departments
    where DEPARTMENT_ID  = :pDeptIdA LOV has been defined on the DepartmentId attribute of the EmployeesView.
    The lovDepartmentImpl overrides the executeQueryForCollection to set the bind variable value.
        @Override
        protected void executeQueryForCollection(Object object, Object[] object2,
                                                 int i) {
            setNamedWhereClauseParam("pDeptId", "50");       
            super.executeQueryForCollection(object, object2, i);
        }When using an ADF form to create a new employee the DepartmentId lov is empty.
    Enabling SQL tracing shows the following :
    [370] _LOCAL_VIEW_USAGE_model_EmployeesView_lovDepartment1_0 ViewRowSetImpl.doSetWhereClause(-1, pDeptId, null)
    [371] _LOCAL_VIEW_USAGE_model_EmployeesView_lovDepartment1_0 ViewRowSetImpl.execute caused params to be "un"changed
    [372] Column count: 4
    [373] _LOCAL_VIEW_USAGE_model_EmployeesView_lovDepartment1_0 ViewRowSetImpl.doSetWhereClause(-1, pDeptId, null)
    [374] _LOCAL_VIEW_USAGE_model_EmployeesView_lovDepartment1 ViewRowSetImpl.setNamedWhereClauseParam(pDeptId, 50)
    [375] ViewObject: _LOCAL_VIEW_USAGE_model_EmployeesView_lovDepartment1 Created new QUERY statement
    [376] _LOCAL_VIEW_USAGE_model_EmployeesView_lovDepartment1>#q computed SQLStmtBufLen: 235, actual=195, storing=225
    [377] SELECT Departments.DEPARTMENT_ID,
           Departments.DEPARTMENT_NAME,
           Departments.MANAGER_ID,
           Departments.LOCATION_ID
    FROM DEPARTMENTS Departments
    where DEPARTMENT_ID  = :pDeptId
    [378] Bind params for ViewObject: _LOCAL_VIEW_USAGE_model_EmployeesView_lovDepartment1
    [379] For RowSet : _LOCAL_VIEW_USAGE_model_EmployeesView_lovDepartment1_0
    [380] Binding null of type 12 for "pDeptId"
    [381] No Resource Bundle found but null value id:LOV_DepartmentId_LOVUIHints_NullValueId is defined in an ListBinding Definition.It would seem that 2 lovDepartment instances are used one at line 370 LOCALVIEW_USAGE_model_EmployeesView_lovDepartment1_0
    and one at line 374 LOCALVIEW_USAGE_model_EmployeesView_lovDepartment1
    The one at line 374 LOCALVIEW_USAGE_model_EmployeesView_lovDepartment1 gets the variable bound at line 374
    however LOCALVIEW_USAGE_model_EmployeesView_lovDepartment1_0 gets a null value and would explain the empty LOV
    Can anybody explain what is happening here ? (and how to use bind variables in LOV queries)
    Regards
    Paul
    (bump)
    Edited by: Paul (MITsa) on Jul 14, 2009 10:46 AM
    I've now tried all types of LOV from ChoiceList to Radio groupe by testing the application module - none of them work.....
    Edited by: Paul (MITsa) on 14-Jul-2009 22:52

    when you rinvoke executeQueryForCollection the bind variables are allready set and they exist in Object[] object2 method parameters.
    in order to change them you need something like:
    private void changeGenericBindVariable(Object[] params, String paramName, Object paramValue) {
    for (int i = 0; i < params.length; i++) {
    if (paramName.equals(((Object[])params)[0].toString()))
    ((Object[])params[i])[1] = paramValue;
    * executeQueryForCollection - overridden for custom java data source support.
    protected void executeQueryForCollection(Object qc, Object[] params,
    int noUserParams) {
    changeGenericBindVariable(params, "pDeptId", "50")
    super.executeQueryForCollection(object, object2, i);
    But its better to set bind variables before you executeQueryForCollection. like when you invoke LOV.
    For cascading LOVs and the problems i have check:
    [http://adfbugs.blogspot.com/2009/07/jdeveloper-11-r1-cascading-lov-bugs.html]

  • Using bind variables with sql statements

    We connect from a VB 6.0 program via OO4O to an Oracle 8.1.7 database, using bind variables in connection with select statements. Running ok, but performance again by using bind vars not as good as expected!
    When looking into the table v$sqlarea, we were able to detect the reason. We expected that our program submits the sql statement with bind vars, Oracle parses this once, and with each select statement again, we do not have a reparse. But: It seems that with each new session Oracle reparses the sql statement, that is, Oracle is not able to memorize or cache bind vars and statements. Even more worrying, this kind of behaviour was visible with each new dynaset, but the same database/session.
    Is there anybody our there with an idea of what is happening here?
    Code snippet:
    Dim OraSession As OracleInProcServer.OraSessionClass
    Dim OraDatabase As OracleInProcServer.OraDatabase
    Set OraSession = CreateObject("OracleInProcServer.XOraSession")
    Set OraDatabase = OraSession.OpenDatabase(my database", "my connect", 0&)
    OraDatabase.Parameters.Add "my_bind", 0, ORAPARM_INPUT
    OraDatabase.Parameters("my_bind").DynasetOption = ORADYN_NOCACHE
    OraDatabase.Parameters("my_bind").serverType = ORATYPE_NUMBER ' Bind Var Type
    Dim RS As OracleInProcServer.OraDynaset
    strSQLstatement= "Select * from my_table where igz= [my_bind] "
    Set RS = OraDatabase.CreateDynaset(strSQLstatement, &H4)
    OraDatabase.Parameters("my_bind").Value = myValue
    RS.Refresh
    Cheers and thanks a lot :)
    Michael Sonntag

    We connect from a VB 6.0 program via OO4O to an Oracle 8.1.7 database, using bind variables in connection with select statements. Running ok, but performance again by using bind vars not as good as expected!
    When looking into the table v$sqlarea, we were able to detect the reason. We expected that our program submits the sql statement with bind vars, Oracle parses this once, and with each select statement again, we do not have a reparse. But: It seems that with each new session Oracle reparses the sql statement, that is, Oracle is not able to memorize or cache bind vars and statements. Even more worrying, this kind of behaviour was visible with each new dynaset, but the same database/session.
    Is there anybody our there with an idea of what is happening here?
    Code snippet:
    Dim OraSession As OracleInProcServer.OraSessionClass
    Dim OraDatabase As OracleInProcServer.OraDatabase
    Set OraSession = CreateObject("OracleInProcServer.XOraSession")
    Set OraDatabase = OraSession.OpenDatabase(my database", "my connect", 0&)
    OraDatabase.Parameters.Add "my_bind", 0, ORAPARM_INPUT
    OraDatabase.Parameters("my_bind").DynasetOption = ORADYN_NOCACHE
    OraDatabase.Parameters("my_bind").serverType = ORATYPE_NUMBER ' Bind Var Type
    Dim RS As OracleInProcServer.OraDynaset
    strSQLstatement= "Select * from my_table where igz= [my_bind] "
    Set RS = OraDatabase.CreateDynaset(strSQLstatement, &H4)
    OraDatabase.Parameters("my_bind").Value = myValue
    RS.Refresh
    Cheers and thanks a lot :)
    Michael Sonntag

Maybe you are looking for

  • WRT310N V1 doesn't let me print

    Hi all, My modem crashed and I purchased a new one. When I reconnected the Linksys router nothing worked so I reinstalled the Linksys software. I now have internet connection and WiFi but I can't print. I reinstalled the printer software and it didn'

  • Print que pauses

    New install of Mavericks. We are a print shop. Normally we print to our RIP. There is no install drivers likea  normal printer. I had a ppd file and when I set up the printer I select it from this list as you see in the picture [URL=http://s80.photob

  • Microsoftteredotunnelingadaptor

    i have problem with my microsoft adaptor, it says devise can,t work code 10, i can,t even use my printer with this problem. please help me.

  • Program Error when Using PS Background Eraser

    Each time I use Background Erase, I get Program Error.  Anyone else having this issue or know of a solution?

  • Table for successor and predecessor data

    Hi Gurus, Can I know the table in which the successor and predecessor data for a process order  is maintained. Thanks Edited by: sai@SAP on Feb 20, 2012 11:46 AM