To unicode or not to unicode, that is my question

tmackin

Reputable Poster
We will be starting to develop our conversion plan from Xe to 8.10 soon. I am not sure I understand the ramifications of this "unicode" thing. Is it mandatory? If not mandatory, what are the benefits? Are there lots of gotchas?

TIA and all the best in the new year!!
 
Tim,

We just upgraded to 8.9, and the Unicode conversion was NOT mandatory. It would be useful if you have international users where a wider character set would be beneficial. We didn't need that functionality, so decided to skip Unicode -- at least for now.

I did run into major problems with the Unicode conversion program, and worked on it for months with PeopleSoft support, but with no resolution. I finally gave up in disgust, plus there were more urgent bugs to eradicate.
 
Last March, we installed 8.9 without using Unicode for the buisness data. We had problem after problem, including some corruption of custom code, until we gave up and installed 8.10 with Unicode in August. Since then we have not had the problems.
 
Hi Tim,

From what I understand, Central Object MUST be UNICODE and Business Date does not need to be UNICODE. I'm starting my first upgrade next week, and I'm going on that premise. If I'm wrong, please somesone correct me.

Thanks

Happy New Year.
 
Another consideration for unicode is that unicode will require additional disk space. There is information on the Peoplesoft web site that states you will need as much as 40% of additional disk space. I personally can't confirm this, but it makes sense if you consider unicode uses two bytes per character. This makes unicode practical for central objects databases (unless you build cross reference tables), but less practical for Business Data and Control Tables databases. This is probably why they are not forcing people to use unicode for all databases.
 
Even if you don't convert your Business Data to Unicode, the programs are using Unicode. So for every read, your programs are converting the data to a unicode format in order to process it. That is the pay off. Either you bite the disk bullet and convert business data, or you use more processor time converting data to unicode when it's processed by OneWorld programs. There is a performance hit probably both ways, so it's a matter of if you have a big CPU or large pipe for your disk controllers as to which way to go.
 
I have been porting code from Xe to 8.9 WITH unicode.

The slimmer (the tool used to convert non unicode 'C' to unicode 'C') does a pretty good job with 90% of the code. A code review should be done on every custom 'c' objects to make sure the job was done properly. The tool has difficulties with, for example, cache index initialization. It leaves sizeof(szVariable) instead of using DIM(szVariable). You'll understand when you convert your first object :)

If you have custom 'c' modules, you'll have a small learning curve to go through.

We haven't experienced data corruption with unicode enabled in Business Data data sources.

good luck with your upgrade!
 
Jean, as always, is exactly correct. With 8.9 and above, you MUST have everything converted to Unicode except for Business Data and Control Tables.

You WILL take a performance hit, with everything else staying the same, if you simply compare XE in non-unicode to 8.10 with Unicode, even if BD and CT are converted. Now, since most upgrades also include hardware upgrades, obviously the amount of performance degradation can be managed.

However, as Jean stated, if you elect not to convert to Unicode (and there are other considerations other than disk space), E1 will perform a non-unicode to unicode back to non-unicode conversion for anything in the BD or CT areas. When comparing a system with the Unicode conversions performed for everything to the same system without, there is a 25 - 35% difference in performance.

You can continue not to convert BD and CT's to Unicode for 8.11, and 8.12. You can also perform the BD and CT Unicode conversions AFTER the upgrade if desired.

Regards,
 
Back
Top