db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Van Couvering (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-20) LIKE handles strings with control characters incorrectly.
Date Thu, 21 Jul 2005 20:17:54 GMT
    [ http://issues.apache.org/jira/browse/DERBY-20?page=comments#action_12316408 ] 

David Van Couvering commented on DERBY-20:

This issue came up with EJBQL testing of the app server here at Sun.  I am including some
comments from the folks doing the testing (Sailaja Rao).  Hopefully this will help us resolve
this item

The below EJBQL query
> when run does not return any dataset.  When it is supposed to return the
> following as possible matches :
> Ber%in
> Ber%lin
> '\' *
> where the dataset contains the values :
> insert into LIKEESCAPE values('1', 'Berlin');
> insert into LIKEESCAPE values('2', 'Ber_in');
> insert into LIKEESCAPE values('3', 'Ber\in');
> insert into LIKEESCAPE values('4', 'Ber%in');
> insert into LIKEESCAPE values('5', 'Berin');
> insert into LIKEESCAPE values('6', 'Ber%lin');

Here is the SQL statement, when the test is executed. I am also attaching the server.log file.

statement<select t0."CUSTNO", t0."NAME" from "LIKEESCAPE" t0 where t0."NAME" LIKE ?  ESCAPE
? > with input values:java.lang.String:Ber\%%, java.lang.Character:\|#]

> LIKE handles strings with control characters incorrectly.
> ---------------------------------------------------------
>          Key: DERBY-20
>          URL: http://issues.apache.org/jira/browse/DERBY-20
>      Project: Derby
>         Type: Bug
>   Components: SQL
>     Versions:
>     Reporter: Tulika Agrawal
>     Priority: Minor
>  Attachments: server.log
> Reporting for Daniel John Debrunner.
> If a string contains control characters in the regions matched 
> by wild card characters then in some situations a LIKE will 
> return false instead of true and the row will not be returned.
> Caused by the dynamic like optimization using >= with a prefix 
> which is is equivalent to >= on the prefeix appended with 
> blanks and not null (\u0000) characters.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message