Received word that our adapter will be changing to support a Unicode environment (we are ASCII today). Looking for input from those with experience in this type of change and how it impacted WebFOCUS report code, functions, report caster (bursting), etc. Specifically targeting discussions on An > AnV format changes, though interested in any other gotcha's or areas to pay special attention to.

PS: In Focus for 6+ years. First Forum post. Woo.

This message has been edited. Last edited by: Tamra,

In a nutshell, no biggie.

For a little more detail, you are probably going to want to use UTF8 as the default encoding type for Unicode characters. For WF, that means changing the default code pages of: WFRS, RC, WF Client and Tomcat (or whatever app server you are using). If you miss one of those, then things can get pretty confusing.

For flat file sources, you are going to want to add the CODEPAGE=XXX to the masters. Otherwise it will use the WFRS default. You also may have to rebuild flat file master files, as you may have to define your strings as byte based (e.g. An => AnB, and AnV => AnBV or something like that).

Your functions (like SUBSTR and POSIT) should remain unchanged, as they are character based and not byte based.

Things that may bite you in the arse are -READ and ON TABLE HOLD FORMAT ALPHA. I believe it was fixed for your release, but some versions of the server did byte based -READ rather than character based. Change those to -READFILE and problem solved. For hold files, ALPHA based holds multiply string by 3 when assigning space for the file. This is to accommodate potential multi byte characters. So hold files could increase space usage by a factor of 3. Use a deliminator based hold and that problem will also go away as well.

Hope this helps

Tina,

Welcome to Focal Point!

I hope you find the forum a great resource, we have a lot of very knowledgeable contributors.

If you found Darryl's post helpful please let us know either way. We also encourage you to then mark the subject line - Tag your topic with keywords

Feel free to assist others as well too -

Thank you for participating in the Focal Point Forum!
Tamra Colangelo
Focal Point Moderator
Information Builders

quote:

For hold files, ALPHA based holds multiply string by 3 when assigning space for the file. This is to accommodate potential multi byte characters. So hold files could increase space usage by a factor of 3. Use a deliminator based hold and that problem will also go away as well.

A result of the above can be that HOLD-files of type FOCUS that barely stay within their size/width limits in your ASCII-based environment will break, because they will exceed those limits with UNICODE encoding.
Format XFOCUS is better at handling that, but not all operations are compatible with XFOCUS (DB_INFILE for example).

Also, long An/AnV columns can exceed the limit that FOCUS can handle. For example, an A4000V column will now require up to 12000 bytes, acting as if it were an A12000V column in ASCII land.