Focal Point Banner


As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.

Join the TIBCO Community
TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.

  • From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
  • Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
  • Request access to the private WebFOCUS User Group (login required) to network with fellow members.

Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.


Focal Point    Focal Point Forums  Hop To Forum Categories  WebFOCUS/FOCUS Forum on Focal Point     [Solved] Unicode evaluation in report with a defined field

Read-Only Read-Only Topic
Go
Search
Notify
Tools
[Solved] Unicode evaluation in report with a defined field
 Login/Join
 
DomR
Member
posted
I have a report on names, some of which contain European characters with accents.

TABLE FILE CUSTOMER
...
BY GIVENNAME
BY FAMILYNAME
...
ON TABLE PCHOLD FORMAT HTML
END
-RUN

The codepage is set to 137. Like this, the names are evaluated correctly, e.g.
Bénédicte Moreaux
...

However, when I define a new field to combine the name fields, and include it in the report, something unexpected happens: this seems to break the Unicode evaluation, not only in the new field but all fields.

DEFINE FILE CUSTOMER
FULLNAME/A100 = GIVENNAME | ' ' | FAMILYNAME
END

TABLE FILE CUSTOMER
...
BY FULLNAME
BY GIVENNAME
BY FAMILYNAME
...
ON TABLE PCHOLD FORMAT HTML
END
-RUN

(I simplified the definition of FULLNAME here for the purpose of the question. It actually contains a few more name fields and nested IFs for which this type of concatenation works well.)

The output now comes out as
Bénédicte Moreaux Bénédicte Moreaux
...

I consulted this page on Unicode support in the technical library but did not see how it could help solve this problem.

How can I fix this?

This message has been edited. Last edited by: Kathleen Butler,


WebFOCUS 7.7.03
Windows 7 64-bit
 
Posts: 17 | Registered: February 23, 2016Report This Post
Wep5622
Virtuoso
posted Hide Post
I don't think that can work correctly with codepage 137. You really need a unicode capable codepage for that (utf-8 usually).

Unfortunately, changing the WFRS code page from a single-byte code page to a multi-byte code page opens up a can of worms that so far prevented us from doing so...

For example, creating FOCUS databases where the combined fields previously just fit within a single segment will now overflow the segment and cause an error upon holding the file. Of course, that can be fixed by changing the code that creates such files, but how do we know which (and how many) need fixing eh? That's going to be a game of whack-a-mole...


WebFOCUS 8.1.03, Windows 7-64/2008-64, IBM DB2/400, Oracle 11g & RDB, MS SQL-Server 2005, SAP, PostgreSQL 11, Output: HTML, PDF, Excel 2010
: Member of User Group Benelux :
 
Posts: 1669 | Location: Enschede, Netherlands | Registered: August 12, 2010Report This Post
dhagen
Virtuoso
posted Hide Post
For you to get the results you have I suspect that your WFRS is set to codepage 65001. You probably have the WF web application set to the same. However, Tomcat - or what ever app server you have - is probably running with a single byte codepage. If it is Tomcat, change the default file encoding to UTF8 (-Dfile.encoding=UTF8) in the start up Java Options.


"There is no limit to what you can achieve ... if you don’t care who gets the credit." Roger Abbott
 
Posts: 1102 | Location: Toronto, Ontario | Registered: May 26, 2004Report This Post
dhagen
Virtuoso
posted Hide Post
quote:
Originally posted by Wep5622:
For example, creating FOCUS databases where the combined fields previously just fit within a single segment will now overflow the segment and cause an error upon holding the file. Of course, that can be fixed by changing the code that creates such files, but how do we know which (and how many) need fixing eh? That's going to be a game of whack-a-mole...


You can adjust the codepage for the FOCUS masters to prevent this. However, if you change the server codepage to 65001 and you generate the FOCUS files using an ON TABLE HOLD, then you are SOL.


"There is no limit to what you can achieve ... if you don’t care who gets the credit." Roger Abbott
 
Posts: 1102 | Location: Toronto, Ontario | Registered: May 26, 2004Report This Post
DomR
Member
posted Hide Post
Thank you. I only saw codepage 137 set in the master files and assumed this was used at every step in the reporting process. I will ask our WebFOCUS administrator if changing to 65001 wherever needed is an option.


WebFOCUS 7.7.03
Windows 7 64-bit
 
Posts: 17 | Registered: February 23, 2016Report This Post
  Powered by Social Strata  

Read-Only Read-Only Topic

Focal Point    Focal Point Forums  Hop To Forum Categories  WebFOCUS/FOCUS Forum on Focal Point     [Solved] Unicode evaluation in report with a defined field

Copyright © 1996-2020 Information Builders