Issue Details (XML | Word | Printable)

Key: DERBY-3315
Type: Task Task
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Mamta A. Satoor
Reporter: Mamta A. Satoor
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Derby

Should UCS_BASIC character types have to look at collation elements when dealing with escape character in the LIKE clause?

Created: 11/Jan/08 06:09 AM   Updated: 16/Jan/08 09:48 PM
Return to search
Component/s: JDBC
Affects Version/s: 10.3.1.4, 10.3.2.1, 10.4.1.3
Fix Version/s: 10.3.3.0, 10.4.1.3

Time Tracking:
Not Specified

Resolution Date: 16/Jan/08 09:48 PM


 Description  « Hide
Code in SQLChar.like(dvd, dvd) method at line number 1767 is executed for non-national/non-collation sensitive character types ie for UCS_BASIC character types and the code looks as follows
  // Make sure we fail for both varchar an nvarchar
  // for multiple collation characters.
  SQLChar escapeSQLChar = (SQLChar) escape;
  int[] escapeIntArray = escapeSQLChar.getIntArray();
  if (escapeIntArray != null && (escapeIntArray.length != 1))
  {
  throw StandardException.newException(SQLState.LANG_INVALID_ESCAPE_CHARACTER,new String (escapeSQLChar.getCharArray()));
   }

It appears that we are trying to see if number of collation elements associated with escape character is more than 1 and if yes, then we throw exception. Seems like a code like above should be done for collation sensitive character types and not for UCS_BASIC character types. Interestingly, nothing like this is getting checked for national character datatypes.

This behavior was detected while working on DERBY-3302

 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
No work has yet been logged on this issue.