We have a customer record with the last name CHEN (accent over the E - a French name). We tried searching multiple ways to locate this record, search resutls below:
Search By
CHE Produces no CHEN records
CH Returns CHEN, however, in an unexpected, non alphabetical, location (below CHIP and above CHOA)
Also, Crystal reports in the LAST_FIRST field cuts off the data at CH.
Do others have multple languages (French and English) where accent marks are required, how do you compensate for this? Might there be an iMIS database patch which will allow the acceptance of this special character and others like it (accent over the n]?
What happens?
What you're dealing with is generally called accent folding. It's similar to case folding, where upper and lowercase letters are treated as the same letter. Case folding is pretty common, but U.S. companies don't often think about accent folding.
Since this website doesn't seem to preserve the accents on your characters, I can't tell if you were searching using E with an accent or without. Are the results different?
More to the point, what would you like to happen? Should users have to type the character with an accent to find this person, or do you want characters with accents folded when searching?
As of today, iMIS uses different technologies for different parts of the system. The core desktop software uses Omnis7, which only understands 8-bit ASCII. For this reason, the iMIS database also uses 8-bit character formats (varchar) instead of unicode formats (nvarchar). Some of the more recent desktop modules use ActiveX, which may or may not understand different code pages depending on how they are written. The .NET portions of iMIS (staff web view, iMIS public view, WCM) are usually capable of handling unicode characters more intelligently. Even when these modules understand wider character sets, the data has to be stored in 8-bit ASCII, so some special characters will be lost. SQL can be configured to ignore accents when searching and sorting, but some of those decisions are made by other software, so reconfiguring SQL probably wouldn't help much.
Further complicating things, searching for the same thing in different areas may give different results. The desktop software's search by name uses LAST_FIRST which can have special characters removed. Adhoc searches and IQA queries will look at the actual contents of the field you choose. Web-based searches are likely to do something special with apostrophes (O'Malley, D'Artagnan) which other areas may not care about, but since the various web offerings from ASI were written by different people in different decades, they may not even be 100% consistent among themselves.
I can tell you that the move to .NET technologies seems to be bringing us closer to a solution for this. ASI is working hard to support non-US-English. Until we get there, your best bet is to contact ASI Tech Support, let them know what you did, what you expected to happen, and what you got instead. They may be able to fix some of the worst problems until the older parts of iMIS can be retired for good.
--
Bruce Wilson
Director, Technical Services
RSM McGladrey, Inc.