Services Partners Company
Knowledge Base


Article

Unique FIND with BEGINS inconsistent depending on database codepage and collation

« Go Back

Information

 
EnvironmentProduct: OpenEdge
Version: 11.5.x, 11.6.x
OS: All supported platforms
Question/Problem Description
Unique FIND <table> WHERE <field> BEGINS <string> statement raises error "More than one <table> records found by a unique FIND. (3166)" if database codepage is single-byte codepage (ISO8859-1)
After converting database to use UTF-8 codepage and loading ICU-* collation, this FIND statement returns a record instead of raising an error.

This is seen when there is a single record that is an exact match for the "<field> BEGINS <string>" query criteria.
This is seen when the character field the BEGINS is used for is leading part in a multi-part index.
This is not seen if the database is converted to UTF-8 codepage without loading new collations / when keeping collation at "Basic".
Steps to Reproduce
Clarifying Information
This is a behavior change. in earlier releases (OpenEdge 10.2B08), the behavior is the same regardless of database codepage - error 3166 is raised regardless of codepage.

Attached .zip file contains test case to demonstrate the behavior.

Expected behavior is that if there's a single exact match on the begins, the record is returned and the error 3166 is not raised even if there are non-exact matches. See 000033038, Unique FIND using BEGINS doesn't return error 3166 as expected. for more details.
Error MessageMore than one <table> records found by a unique FIND. (3166)
Defect/Enhancement NumberDefect PSC00353314, PSC00353905
Cause
2 defects, with same visible symptoms:
PSC00353314 -> Regression issue introduced by the fix for PSC00173160 (see also 000077128, Error (138) executing a FIND-UNIQUE method, the CAN-FIND function or the unique FIND statement against a UTF-8 database.)
PSC00353905 -> Issues in database engine where it failed to test if field in BEGINS was last field component of index or not. Also covers issue where ROWIDs go into 64-bit range (includes Partitioned tables)
Resolution
The fix for this issue is expected to be in the upcoming release OpenEdge 11.7. As of February 17 2017, release OpenEdge 11.7 is scheduled to be released in Q2 2017, although dates and content of the release are subject to change.
Workaround
Notes
Attachment
Disclaimer

The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.



Feedback
 
Was this article helpful?

   

Your feedback is appreciated.

Please tell us how we can make this article more useful.



Characters Remaining: 255