PreparedStatements and LIKE clauses

Hi,
I've come across a slight problem with PreparedStatements and LIKE clauses. Say I want my query to look something like this:
SELECT * FROM CONTENT_TABLE WHERE CONTENT LIKE '%test%'If I were to use a PreparedStatement I'd do something like this:
PreparedStatement searchContent = con.prepareStatement("SELECT * FROM CONTENT_TABLE WHERE CONTENT LIKE ?");
searchContent.setString(1, queryString);This isn't correct becuase it matches where CONTENT LIKE 'queryString'
I tried this:
PreparedStatement searchContent = con.prepareStatement("SELECT * FROM CONTENT_TABLE WHERE CONTENT LIKE '%?%'");
searchContent.setString(1, queryString);But I get a syntax error in my SQL.
Is there another way around this?
Thanks

just guessing try this:
PreparedStatement searchContent = con.prepareStatement("SELECT * FROM CONTENT_TABLE WHERE CONTENT LIKE '%?%'");searchContent.setString(1, "%"+queryString+"%");
This might work, since ? gets replaced by '...', so i am guessing %..% will fit..
give it a shot, i might be wrong.

Similar Messages

  • PreparedStatement and "in" clause

    I am trying to pass an "in" clause to a SQL statement as a bind variable, but keep getting an "invalid number" runtime error:
    The "where" clause of the SQL statement is:
    String wherestmnt = "where sh.header_id in ? ";
    I am using a PreparedStatement and am setting the bind variable as follows:
    pstmt.setString(1,"(34552)")
    If I change the "in" clause to "=" and do a set as pstmt.setString(1,"34552") it works fine.
    Any advice?
    null

    There is also another error. If you need to use the in clause the values must be within paranthesis,
    So if your query were like,
    select * from emp where empno in (?)
    then the bind would work. You can have as many ? as you want separated by commas and you can bind that many values..!

  • PreparedStatement and LIKE

    Can I use LIKE in a preparedStatement?
    String selectTwo =
    "SELECT zip_code " +
    "FROM alk_zip " +
    "WHERE zip_code LIKE ? " +
    "ORDER BY zip_code";
    PreparedStatement stmtTwo = con.prepareStatement( selectTwo );
    // loop starts here
    stmtTwo.setString( 1, "'" + partial + "%'" );
    // that's double-quote single-quote double-quote + partial + double-quote
    percent single-quote double-quote
    rsTwo = stmtTwo.executeQuery();
    // we only want the first match
    if ( rsTwo.next() )
    ZipCodes.add( rsTwo.getString( 1 ).trim() );
    // loop ends here
    Does this look correct? I'm not getting any results. If I don't use a
    prepared statement and construct the SQL Select every time, I get the
    results I'm expecting.

    Yep, setString already adds the appropriate quotes to your parameter.
    Nils
    Eric F wrote:
    >
    I figured it out.
    It should be:
    stmtTwo.setString( 1, partial + "%" );
    instead of:
    stmtTwo.setString( 1, "'" + partial + "%'");
    "Eric F" <[email protected]> wrote in message
    news:3be17308$[email protected]..
    Can I use LIKE in a preparedStatement?
    String selectTwo =
    "SELECT zip_code " +
    "FROM alk_zip " +
    "WHERE zip_code LIKE ? " +
    "ORDER BY zip_code";
    PreparedStatement stmtTwo = con.prepareStatement( selectTwo );
    // loop starts here
    stmtTwo.setString( 1, "'" + partial + "%'" );
    // that's double-quote single-quote double-quote + partial + double-quote
    percent single-quote double-quote
    rsTwo = stmtTwo.executeQuery();
    // we only want the first match
    if ( rsTwo.next() )
    ZipCodes.add( rsTwo.getString( 1 ).trim() );
    // loop ends here
    Does this look correct? I'm not getting any results. If I don't use a
    prepared statement and construct the SQL Select every time, I get the
    results I'm expecting.
    ============================
    [email protected]

  • SQL error with LIKE clause in statement

    Can anyone explain how an SQL statement with a LIKE clause is executed properly?
    Seems like it ought to be cut and dried, no pun intended!
    When I run the following and set the requestor name = ?, and correctly type in the entire name, a result set (albeit abbreviated) will return.
    But if I try to set the request param to LIKE I get an error of some kind, either invalid cursor state or NullPointer exception.
    Here's my code.
    Statement selstmt = connection.createStatement();          
    String preparedQuery = "SELECT DISTINCT AID, ACTIVE, REQUESTOR_NAME,REQUESTOR_EMAIL" +
    " FROM CHANGE_CONTROL_USER, CHANGE_CONTROL_ADMIN " +
    " WHERE REQUESTOR_NAME LIKE '%?%';";
      String reqName = request.getParameter("requestor_name");
    PreparedStatement prepstmt = connection.prepareStatement(preparedQuery);
    prepstmt.setString(1, reqName);
    ResultSet rslts = prepstmt.executeQuery();
    rslts.next();
    int aidn = rslts.getInt(1);          
    int actbox = rslts.getInt(2);      
    String reqname = rslts.getString(3);
    String reqemails = rslts.getString(4);It's also returning only 1 record for some reason, as I have the following:
    <% while (rslts.next()) { %>
      <tr class="style17">
        <td><%=reqname%></td>
    <td><%=reqemails%></td>
       <td><%=actbox %></td>
        <td><%=aidn %></td>
      </tr>
      <%
    rslts.close();
    selstmt.close();
    %>If I use
    " FROM CHANGE_CONTROL_USER, CHANGE_CONTROL_ADMIN " +
    " WHERE REQUESTOR_NAME = ?;";it will actually spit out the name and corresponding email properly, albeit just one record like I said.
    Is there some kind of escape sequence I should be using that I'm not?
    And why just the one record?
    Any help or direction is appreciated!
    Thanks.

    I have working code for LIKE in PreparedStatement, and its equivalent in your case is something like this:Statement selstmt = connection.createStatement();          
    String preparedQuery = "SELECT DISTINCT AID, ACTIVE, REQUESTOR_NAME,REQUESTOR_EMAIL" +
    " FROM CHANGE_CONTROL_USER, CHANGE_CONTROL_ADMIN " +
    " WHERE REQUESTOR_NAME LIKE ?";
      String reqName = request.getParameter("requestor_name");
    PreparedStatement prepstmt = connection.prepareStatement(preparedQuery);
    prepstmt.setString(1, "%" + reqName.trim() + "%");
    ResultSet rslts = prepstmt.executeQuery();
    rslts.next();
    int aidn = rslts.getInt(1);          
    int actbox = rslts.getInt(2);      
    String reqname = rslts.getString(3);
    String reqemails = rslts.getString(4);

  • PreparedStatement with IN clause

    Hi,
    I have a question regarding using a PreparedStatement and a query
    using an IN clause.
    I need to pass an array of values to using an IN clause. How does the
    binding work in this case since I am getting an SQLException - Invalid
    column type ?
    I need to pass an array of longs to this query.
    The java.sql.Array does not have an implementation. How does this do
    this ?

    Aswin Dinakar wrote:
    >
    Thanks a lot ! You really understood my problem without me describing it
    properly.
    I dont mind keeping it as a statement but that statement is being executed in
    a FOR loop thousands of times and its a very complex SQL with lots of joins
    and its taking up a lot of the CPU. Time constraint prevent me from changing
    the business logic.I also suggest making a stored procedure to do the complex stuff. At least the
    DBMS will only have to parse it once. The argument could even be a string
    like "1,2,3,4,5,6", and the procedure could handle separating the values.
    In a related issue do you know if the JMS database updates(deletes mostly) for
    WLS 5.1 are PreparedStatement(s) ? When I query the v$sqlarea table for the
    parse counts I see lots of JMS updates to the database.yes they are, but our MS SQLServer driver is inefficient about SQL with
    PreparedStatements, sending fresh SQL to be parsed each execution. I suggest
    your trying the MS driver from www.inetsoftware.de, which will do a better jod
    than ours in this area.
    Joe
    >
    Joseph Weinstein wrote:
    A PreparedStatement only allows settable parameters representing
    single values. You can't do:
    stmt = c.prepareStatement("select * from foo where key in ?");
    stmt.setString(1, "(1,2,3,4,5,6)");
    Therefore, you need to know how many values in your In clause,
    and generate a PreparedStatement like:
    stmt = c.prepareStatement("select * from foo where key in (?,?,?,?,?...");
    with a '?' for every value. Depending on whose driver your using, and
    whether you can keep and re-use PreparedStatments, it might be better
    to simply make the whole SQL query as a simple string and execute it:
    String query = "select * from foo where key in (1,2,3,4,5,6)";
    rs = stmt.executeQuery(query);
    Aswin Dinakar wrote:
    Hi,
    I have a question regarding using a PreparedStatement and a query
    using an IN clause.
    I need to pass an array of values to using an IN clause. How does the
    binding work in this case since I am getting an SQLException - Invalid
    column type ?
    I need to pass an array of longs to this query.
    The java.sql.Array does not have an implementation. How does this do
    this ?

  • Create Index to use Like Clause

    Hi All,
    I want one of my query to use a index which runs with a LIKE Clause. I have not done that before but i have heard and seen through forums that its possible to create indexes for a column with Like Clause using function based index.
    Function
    Request the forum users to achieve my objective. Let me list down what i have done.
    Function
    CREATE OR REPLACE FUNCTION RND_LIKE(P_NO IN VARCHAR2)
    RETURN VARCHAR2 IS
    RESULT VARCHAR2(240);
    BEGIN
    RETURN P_NO||'%';
    END RND_LIKE;
    SELECT ENAME FROM EMP WHERE ENAME LIKE RND_LIKE('A')
    Here based on this function i want to create a function based index and force the same to my query. Request the forum users to help me out in this.
    Thanks
    Edited by: ramarun on Dec 18, 2009 9:26 PM

    In the case you had there , Oracle would use an index on ename in a query if you were to type A% in the ename item on a Form. You wouldn't need a function index for that.
    Here's the link to the documentation to create a function based index http://download-uk.oracle.com/docs/cd/B28359_01/server.111/b28310/indexes003.htm#i1006674

  • Error bind variable with "like %" clause ?

    Hello everybody;
    I would like to know how to do a like clause to bind variables, with this code i obtain 'ORA-00933: SQL command not properly ended' error
    v_query:= 'UPDATE ' || collection(i) ||' SET REF_PLAN=:quatre_champ WHERE FAM_SIM like ''%'':prem_champ''%'' AND PRISE_V1P like ''%'':deux_champ''%'' AND BROCHE_V1P like ''%:trois_champ%''';
                                  EXECUTE IMMEDIATE v_query USING quatre_champ,prem_champ,deux_champ,trois_champ;Maybe my " ' " are in a bad positions ?
    Thanks for your help, regards.

    Hi,
    try this
    v_query :=
             'UPDATE '
          || collection (i)
          || ' SET REF_PLAN =:quatre_champ WHERE FAM_SIM like'|| '''%:prem_champ%'''
          || ' AND PRISE_V1P like' || ''' %:deux_champ%'''
          || ' AND BROCHE_V1P like'||''' %:trois_champ%;'''
    Of course not tested
    Any efforts to give sample data and help us recreated the problem will be appreciated.
    Cheers!!!
    Bhushan

  • Qualifying Expression and WHERE CLAUSE Extension

    I would like to know the exact difference between 'Qualifying Expression and WHERE CLAUSE Extension'. Since both are meant to contain some CONDITION that would facilitate the Edit Check's success, So I am sometimes a bit confused with these too as to when to use what.
    Can someone help Please??

    As you can tell from my previous posts (requests!) - I'm a newbie to OC.
    From the documentation - it appears that both Qualifying expression and Where Clause work the same way but the way they execute is different.
    Qualifying expression is applied after the fetch (key fields and question response data from DCM cursor i.e., after the cursor fetches the data) and Where clause filters before QG fetch.
    HTH

  • Using Like Clause in Prepared Statement

    Hi,
    I want to use LIKE clause in prepared statement. This is not returning any record.
    This is the query. Please help me in this.
    SELECT EMPLYR_GRP,EMPLYR_GRP_NAME FROM EMPLOYER_GROUP WHERE EMPLYR_GRP_NAME LIKE ? AND EMPLYR_GRP = ?
    This is giving Oracle SQL Error.
    SELECT EMPLYR_GRP,EMPLYR_GRP_NAME FROM EMPLOYER_GROUP WHERE EMPLYR_GRP_NAME LIKE %?% AND EMPLYR_GRP = ?

    The first variant should work just fine as long as you use stmt.setString(1, '%' + pattern + '%') to set the parameter. The second query is just plain wrong.
    Alin.

  • Using PreparedStatement and the Oracle Error ORA-1000

    Hi,
    I have a question about PreparedStatement objects that is not so simple to explain for me. What I would like to know is: if I use a PreparedStatement following traditional and generic steps:
    1- PreparedStatement pStmt = Connection.prepareStatement(sQuery);
    2- pStmt.setXXX(i,j);
    n - pStmt.setXXX(i,j);
    n+1 - ResultSet rs = pStmt.executeQuery();
    n+2 - while(rs.next()){ ... retrive ResultSet data  ... }
    n+3 - rs.close()
    n+4 - back to point number 2
    and at the end (as you can see in the point numbered n+4), instead of closing the PreparedStatement pStmt using the close() method, I reuse the PreparedStatement pStmt comeing back to the point numebr 2 and setting again all its parameters with new values ... then ... what heppens in the Oracle database ? Has been the cursor (so the mamory area), associated to my PreparedStatement object pStmt, duplicated or is it the same ?
    I know that Java allows you to do this kind of operations with PreparedStatement, and I know that in tha Java Documentation is explained to follow this strategy to optimize the execution time because in this way the same PreparedStatement is precompiled and prepared only once. But if I do a for loop following the steps explained before, after many iterations I have the error "ORA-1000: maximum open cursors exceeded". This error is the reason of my question. Does this error means that it's mandatory to close a PreparedStatement always, otherwise if you reuse it without closing it then the corresponding database cursor will be duplicated ? If it is so, then I think this is a contradiction with official java documentation ...
    I'm using Oracle8i (version 8.1.7) and Oracle JDBC Thin Driver (Windows NT) for use with JDK 1.2.x. Moreover, in my database istance the parameter "maximum open cursor" is equal to 800 ...
    Thank you very much for suggestions :-)

    There is no need to close a prepared statement or its resultset for every iteration.
    After the first iteration in a loop, all subsequent executions of it will close the previous resultset. By adding close() method, you are making one extra costly call to the DB for no reason.
    Following is the sample code.I know what you are saying. In fact at the beginning I wrote my code in the same way of your sample (see the code of my first post at the begin of this page).
    But doing so, after thousand iterations of the loop, I had "Oracle Error ORA-1000 : maximun open cursor exeeded" even if in my database istance the parameter "maximum open cursor" is equal to 8000.
    At this moment in my code, for each iteration, I close the PreparedStatement and in this way I don't have anymore the error :-((
    So it seems that only in theory we can reuse a preparedStatement without closing it. In fact if we see the oracle system table "$open_cursor" (as Konrad Pietzka suggest me) we can find that, for each interation,
    at our line code "rs = pstmt.executeQuery();" correspond a new cursor in the database: this means that for each method "pstmt.executeQuery()" the database open a new cursor and do not use the previous one as it should.
    I posted a question two months ago to search if someone had the same problem (it seems that Konrad Pietzka had the same situation) and was able to explain me what is the cause.
    The only reason I found by myself for this problem, is that probably the Oracle JDBC Thin Driver for Windows NT/2000 has some bugs... but I'm not sure ...
    Thank you very much for you time !!
    bye :-))
    Fidalma

  • Execution of subquery of IN and EXISTS clause.

    Hi Friends,
    Suppose we have following two tables:
    emp
    empno number
    ename varchar2(100)
    deptno number
    salary number
    dept
    deptno number
    location varchar2(100)
    deptname varchar2(100)
    status varchar2(100)
    Where dept is the master table for emp.
    Following query is fine to me:
    SELECT empno, ename
    FROM emp,dept
    WHERE emp.deptno = dept.deptno
    AND emp.salary &gt;=5000
    AND dept.status = 'ACTIVE';
    But I want to understand the behaviour of inline query (Used with IN and EXISTS clause) for which I have used this tables as an example (Just as Demo).
    1)
    Suppose we rewrite the above query as following:
    SELECT empno, ename
    FROM emp
    WHERE emp.salary &gt;=5000
    AND deptno in (SELECT deptno FROM dept where status = 'ACTIVE')
    Question: as shown in above query, suppose in our where clause, we have a condition with IN construct whose subquery is independent (it is not using any column of master query's resultset.). Then, will that query be executed only once or will it be executed for N number of times (N= number of records in emp table)
    In other words, how may times the subquery of IN clause as in above query be executed by complier to prepared the subquery's resultset?
    2)
    Suppose the we use the EXISTS clause (or NOT EXISTS clause) with subquery where, the subquery uses the field of master query in its where clause.
    SELECT E.empno, E.ename
    FROM emp E
    WHERE E.salary &gt;=5000
    AND EXISTS (SELECT 'X' FROM dept D where status = 'ACTIVE' AND D.deptno = E.deptno)
    Here also, I got same confusion. For how many times the subquery for EXISTS will be executed by oracle. For one time or for N number of times (I think, it will be N number of times).
    3)
    I know we can't define any fix thumbrule and its highly depends on requirement and other factors, but in general, Suppose our main query is on heavily loaded large transaction table and need to check existance of record in some less loaded and somewhat smaller transaction table, than which way will be better from performance point of view from above three. (1. Use of JOIN, 2. Use of IN, 3. Use of EXISTS)
    Please help me get solutions to these confusions..
    Thanks and Regards,
    Dipali..

    Dipali,
    First, I posted the links with my name only, I don;t know how did you pick another handle for addressing it?Never mind that.
    >
    Now another confusion I got.. I read that even if we used EXISTS and , CBO feels (from statistics and all his analysis) that using IN would be more efficient, than it will rewrite the query. My confusion is that, If CBO is smart enough to rewrite the query in its most efficient form, Is there any scope/need for a Developer/DBA to do SQL/Query tuning? Does this means that now , developer need not to work hard to write query in best menner, instade just what he needs to do is to write the query which resluts the data required by him..? Does this now mean that now no eperts are required for SQL tuning?
    >
    Where did you read that?Its good to see the reference which says this.I haven't come across any such thing where CBO will rewrite the query like this. Have a look at the following query.What we want to do is to get the list of all teh departments which have atleast one employee working in it.So how would be we write this query? Theremay be many ways.One,out of them is to use distinct.Let's see how it works,
    SQL> select * from V$version;
    BANNER
    Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
    PL/SQL Release 11.1.0.6.0 - Production
    CORE    11.1.0.6.0      Production
    TNS for 32-bit Windows: Version 11.1.0.6.0 - Production
    NLSRTL Version 11.1.0.6.0 - Production
    SQL> set timing on
    SQL> set autot trace exp
    SQL> SELECT distinct  D.deptno, D.dname
      2        FROM     scott.dept D,scott.emp E
      3  where e.deptno=d.deptno
      4  order by d.deptno;
    Elapsed: 00:00:00.12
    Execution Plan
    Plan hash value: 925733878
    | Id  | Operation                     | Name    | Rows  | Bytes | Cost (%CPU)| T
    ime     |
    |   0 | SELECT STATEMENT              |         |     9 |   144 |     7  (29)| 0
    0:00:01 |
    |   1 |  SORT UNIQUE                  |         |     9 |   144 |     7  (29)| 0
    0:00:01 |
    |   2 |   MERGE JOIN                  |         |    14 |   224 |     6  (17)| 0
    0:00:01 |
    |   3 |    TABLE ACCESS BY INDEX ROWID| DEPT    |     4 |    52 |     2   (0)| 0
    0:00:01 |
    |   4 |     INDEX FULL SCAN           | PK_DEPT |     4 |       |     1   (0)| 0
    0:00:01 |
    |*  5 |    SORT JOIN                  |         |    14 |    42 |     4  (25)| 0
    0:00:01 |
    |   6 |     TABLE ACCESS FULL         | EMP     |    14 |    42 |     3   (0)| 0
    0:00:01 |
    Predicate Information (identified by operation id):
       5 - access("E"."DEPTNO"="D"."DEPTNO")
           filter("E"."DEPTNO"="D"."DEPTNO")
    SQL>
    SQL> SELECT distinct  D.deptno, D.dname
      2        FROM     scott.dept D,scott.emp E
      3  where e.deptno=d.deptno
      4  order by d.deptno;
        DEPTNO DNAME
            10 ACCOUNTING
            20 RESEARCH
            30 SALES
    Elapsed: 00:00:00.04
    SQL>So CBO did what we asked it do so.It made a full sort merge join.Now there is nothing wrong in it.There is no intelligence added by CBO to it.So now what, the query looks okay isn't it.If the answer is yes than let's finish the talk here.If no than we proceed further.
    We deliberately used the term "atleast" here.This would govern that we are not looking for entirely matching both the sources, emp and dept.Any matching result should solve our query's result.So , with "our knowledge" , we know that Exist can do that.Let's write teh query by it and see,
    SQL> SELECT   D.deptno, D.dname
      2        FROM     scott.dept D
      3          WHERE    EXISTS
      4                 (SELECT 1
      5                  FROM   scott.emp E
      6                  WHERE  E.deptno = D.deptno)
      7        ORDER BY D.deptno;
        DEPTNO DNAME
            10 ACCOUNTING
            20 RESEARCH
            30 SALES
    Elapsed: 00:00:00.00
    SQL>Wow, that's same but there is a small difference in the timing.Note that I did run the query several times to elliminate the physical reads and recursive calls to effect the demo. So its the same result, let's see the plan.
    SQL> SELECT   D.deptno, D.dname
      2        FROM     scott.dept D
      3          WHERE    EXISTS
      4                 (SELECT 1
      5                  FROM   scott.emp E
      6                  WHERE  E.deptno = D.deptno)
      7        ORDER BY D.deptno;
    Elapsed: 00:00:00.00
    Execution Plan
    Plan hash value: 1090737117
    | Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)| Ti
    me     |
    |   0 | SELECT STATEMENT             |         |     3 |    48 |     6  (17)| 00
    :00:01 |
    |   1 |  MERGE JOIN SEMI             |         |     3 |    48 |     6  (17)| 00
    :00:01 |
    |   2 |   TABLE ACCESS BY INDEX ROWID| DEPT    |     4 |    52 |     2   (0)| 00
    :00:01 |
    |   3 |    INDEX FULL SCAN           | PK_DEPT |     4 |       |     1   (0)| 00
    :00:01 |
    |*  4 |   SORT UNIQUE                |         |    14 |    42 |     4  (25)| 00
    :00:01 |
    |   5 |    TABLE ACCESS FULL         | EMP     |    14 |    42 |     3   (0)| 00
    :00:01 |
    Predicate Information (identified by operation id):
       4 - access("E"."DEPTNO"="D"."DEPTNO")
           filter("E"."DEPTNO"="D"."DEPTNO")Can you see a keyword called Semi here? This means that Oralce did make an equi join but not complete.Compare the bytes/rows returned from this as well as cost with the first query.Can you notice the difference?
    So what do we get from all this?You asked that if CBO becomes so smart, won't we need developers/dbas at that time?The answer is , what one wants to be, a monkey or an astranaut? Confused,read this,
    http://www.method-r.com/downloads/doc_download/6-the-oracle-advisors-from-a-different-perspective-karen-morton
    So it won't matter how much CBO would become intelligent, there will be still limitations to where it can go, what it can do.There will always be a need for a human to look all the automations.Rememember even the most sofisticated system needs some button to be pressed to get it on which is done by a human hand's finger ;-).
    Happy new year!
    HTH
    Aman....

  • XSQL Using bind params with sql LIKE clause

    I am unable to use a bind-param with the LIKE clause in a SELECT statement.
    eg call .../temp.xsql?name=N
    XSQL query is this:
    <xsql:query max-rows="-1" bind-params="name">
    SELECT last_name
    FROM emp
    WHERE last_name LIKE '?%'
    </xsql:query>
    I have tried a few combinations so far with no success eg:
    WHERE last_name LIKE '{@name}%'
    WHERE last_name LIKE ?||%
    Any ideas?

    I highly recommend using XSQL's real bind variable feature wherever you can. You can read about it in the XSQL Online Documentation (Search for the "Using Bind Variables" section).
    Using this feature is more performant and more secure than using textual substitution variables.
    Here's what your page looks like using textual substitution:
    <page connection="UTD4" xmlns:xsql="urn:oracle-xsql">
      <xsql:query null-indicator="yes" >
        SELECT * FROM TC_HL7_SEG WHERE SEGMENT_CODE LIKE '{@code}%'
      </xsql:query>
    </page> .
    And here's what it would look like using real bind variables:
    <page connection="UTD4" xmlns:xsql="urn:oracle-xsql">
      <xsql:query null-indicator="yes" bind-params="code">
        SELECT * FROM TC_HL7_SEG WHERE SEGMENT_CODE LIKE ?||'%'
      </xsql:query>
    </page> .
    Using real bind variables allows the database to avoid reparsing the SQL statement everytime, which improves performance.
    Steve Muench
    JDeveloper/BC4J Development Team
    Author, Building Oracle XML Applications

  • Help with Oracle 9i LIKE clauses

    I ma converting an application running against SQLServer to Oracle 9i and have run into two problems:
    1.SQLServer is case-senstive by default but Oracle 9i is, can I change the settings so that it is not.
    2.Oracle does not support the [] operators within a LIKE clause
    In SQLServer I have a like clause of the form:

    Sorry(accidental KeyPress)
    2. In SQLServer have a like clause of the form
    LIKE 'fred[;:., ]'
    which would match fred, and fred followed by any of the characters in the []
    how can I do this in Oracle 9i.
         

  • Difference of 'Specify Fragmentation Content'  and 'where clause Filter ' ?

    What is the difference of ‘Specify Fragmentation Content’ and ‘where clause Filter ‘
    As per my understanding Both looks like limit the data ?

    'Specify Fragmentation Content’ is for Union-ing tables, e.g. one table has data for 2008 while other has 2005-2007, so 'Specify Fragmentation Content’ tells server where to go look for data.
    'Where clause Filter' is for limiting data from the table, e.g. where status = 'Funded'

  • Performance on searching a name field with the like clause

    Hi.  We run 2012 std and I suspect we'll be running into challenges as my user has expressed an interest in searching data based on a like clause across a contact name column that is varchar(80).  The like clause is shown below.  The
    question is whether or not an index on this column will (if we make one) even be used when a like clause is introduced?  And any other advice the community may offer.  I'll ask my user if they could limit the search to patterns that match starting
    in position 1 but suspect they'll say no.  Currently the table has 1.5 million rows , one pk, and is approx 1100 bytes wide if varchars are fully used.
    where ltrim(rtrim(e.[ContactName])) like '%' +IsNull(@contactName1,'') + '%'

    Hi.  We run 2012 std and I suspect we'll be running into challenges as my user has expressed an interest in searching data based on a like clause across a contact name column that is varchar(80).  The like clause is shown below.  The
    question is whether or not an index on this column will (if we make one) even be used when a like clause is introduced?  And any other advice the community may offer.  I'll ask my user if they could limit the search to patterns that match starting
    in position 1 but suspect they'll say no.  Currently the table has 1.5 million rows , one pk, and is approx 1100 bytes wide if varchars are fully used.
    where ltrim(rtrim(e.[ContactName])) like '%' +IsNull(@contactName1,'') + '%'
    Hi db042190,
    >> The question is whether or not an index on this column will (if we make one) even be used when a like clause is introduced?
    A simple index use an exact value in order to compare it (it orer the tree according to the value). For most cases it will not be a good solution for filtering by "like" (in some cases it can help you use "index scan", but it will not
    be able to use "index seek"). There are several options that can help in this issue dapending on your interface and the way you use the data:
    (1) Full Text Index as Olaf mentioned
    (2) Another option, which is very useful in some cases, based on using an external table, which store list of searching words (if the user try a new search then you can scan the original table, which this is one-time-job for each new word). This is actually
    work on the same idea of using FTS, but it is more flexible and give you direct control if you need to use word searching and not phrase/free-text searching. This table is indexed and the search is done on this table, and not the original table. Those two
    tables have relations many-to-many, and you use a simple JOIN to get the results 
    >> limit the search to patterns
    This can be a game changer!
    There is a simple solution that might help you in this case which is very useful! you can create a computed column that store the value according to your patterns, and then create index on that
    column. For example if the your pattern is filter by "starting with 10 specific char" then you can use simple LEFT function like in this code:
    CREATE TABLE t (LongText nvarchar(MAX), MyPatSearch as convert(nvarchar(10),LEFT(LongText,10)));
    GO
    CREATE NONCLUSTERED INDEX IX_MyPatSearch ON t (MyPatSearch);
    GO
    * using computed column with string like in this example, you have to use CONVERT since Data type is requirements for index computed column.
      Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]

Maybe you are looking for