View Incident Report

Serious

Reported By: Luiz Marques
Reported On: 6/30/2000
For: Version 2.02 Build 1

# 565 Accented Characters Being Treated Differently Between Optimized and Un-Optimized Filters

Depending upon whether an index was available or not, partial-length filters and LIKE filters with wildcards (including SQL queries) would return different results for any table using a non-Machine ASCII language driver that also contained data values with accented characters.

Comments

To correct this problem we have changed around the way the indexes handle accented characters with respect to string value comparisons. THIS WILL REQUIRE THAT YOU RUN THE REPAIRTABLE METHOD ON EVERY TABLE THAT USES A NON-MACHINE-ASCII LANGUAGE DRIVER. If you are using a primary index consisting of a string field(s) that relies on a distinction between accented and non-accented characters, it is possible that running the RepairTable method will cause records to be deleted due to primary key violations caused by this change. Please review the contents of your tables beforehand so that you may plan for this eventuality and develop a workaround to prevent data loss. DBISAM now does not take into account accented characters when performing filters and SQL queries, thus the data values FABIO and FÁBIO will both be returned for any filter or SQL query that is searching for FABIO (or FÁBIO). This behavior is now consistent throughout DBISAM.

Resolution

Fixed Problem on 7/1/2000 in version 2.03 build 1

More Support Options

Search Incident Reports

Support Forums

Frequently Asked Questions

Technical Bulletins

Technical Articles

Product Manuals

Roadmap