| | Product(s): | AssetWise Asset Reliability | |
| | Version(s): | rel 6, rel 7 | |
| | Environment: | N\A | |
| | Area: | N/A | |
| | Subarea: | N\A | |
How extensive is the effort to change the character set from ANSI to Unicode
There are 2 aspects of the change, upgrading the data and upgrading the application. Upgrading the data would require a script to be written and to be run to change each piece of data to UTF-8. This will require a resource to run the script and review the results. It is not a significant man-hours task to run the script as the server does all the work once it’s kicked off. But writing and testing of the script and reviewing the results to ensure that the script ran completely successfully may take some time. Upgrading the application code is not required if you’re in a version above 7.0 as it supports Unicode however, you will be required to upgrade code if you want to remain in a version below version 7.0 and have a Unicode database.
What is the best practice for new installs / upgrades?
Our standard practice for new installs is to set them up with Unicode from the start. For existing installs we typically leave the data as it was whether ANSI or Unicode. We may change to Unicode if the user needs to support multiple languages with different character sets, such a Cyrillic.
Do you have (different) clients running databases on either charactersets
We have some clients who run ANSI and some who run Unicode. We don’t keep track of the numbers of who uses which.
There is one big thing that I think will sway users with large databases toward the ANSI side of the scale. Changing your database from ANSI to Unicode would double its size. This makes it harder to share, take longer to upgrade, require more space and may impact on performance. Our recommendation is to keep the existing character set unless using Unicode offers a tangible benefit tat you're interested in using such as multi-language support.
| | Original Author: | Joe Marin | |