We have a name stored in our database as Bañuelos. When it appears on the report output (Excel 2K, PDF, and HTML), it appears as
Ba?uelos. Is there a way to prevent this from happening?

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

Short answer, Yes.

Long answer, you need to be using a font that includes the extended character set (which includes the á é í ó ú ñ ¿ and other such characters) which I believe that the standard fonts do support. I also think that your WF server needs to have a different codepage enabled (for example, 137 which is English/Western Europe(Latin 1). This is not the default and must be changed in the NLS configuration for the server. I believe the default is Standard US English which is codepage 437 and this would not recognize the extended character set.

Thanks Darin. I modified the NLS settings in the WebFocus Admin Console but the name still appears the same in the report.

It may have something to do with the platform or DB you're using.

Please update you signature as per this posting, it may help us to know what your environment is:
Friendly reminder: Please update your signatures

As Francis mentions, we need a little more info about your environment. One other suggestion is to try running the query directly in the admin console and see what you get. You may also have to change NLS settings for the client.

My profile has been updated. I ran the query in the admin console and the result was the same, still getting ? in place of ñ in the name.


Thanks!
Christine

Here's a quick test - in the console, write a quick procedure that has "Bañuelos" in the heading and run it. If it displays correctly, the server is configured properly and we need to look at database issues or possibly platform character translation. If it still displays Ba?uelos we need to keep looking at server configuration.

Hi,

Please set your NLS code page setting to :65001 -unicode (UTF-8)
AND NLS_SEMANTICS TO BYTE

Also go to Reportcaster configuration and set the parameter :
Dsever Code page to 65001
Webserver Code page to 65001
and ZIPENCODING TO cp858

Darin, Bañuelos appears correctly in the heading.

Thanks!
Christine

Do not go to UTF-8 server with nls symantics of byte. This should work fine with a server codepage of 137. Are any other character displaying as a question mark. ñ is ascii 241, how about 242 or 243 òó ?
Is there a CODEPAGE parm in your masterfile?

OK, so I think we can rule out any further issues with codepages. It can display the characters correctly. Now if you insert the field into the heading like

HEADING
"<LASTNAME>"

it displays incorrectly?

Also, you don't mention your DBMS - DB2? Oracle? MS SQL? Can you use a native query tool and get a correct display?

For Cburrel:
We are working in russian language. ( So we have a lot of "strange" symbols )

I suppose you must:
1. Set WF Server NLS = [your codepage] in WebFOCUS Server Console->Configure->NLS
2. Set WF Client NLS = [your codepage] in WebFOCUS Administration Console->Configuration->NLS
3. Possibly :
Set "Save As ANSI" in Developer Studio (if you use it)
Set ReportCaster DServer Codepage (if you use it)
AND even that possible : SET JAVA Settings for Apache Tomcat (if you use it) -Dfile.Encoding =

For Majid:

quote:

Please set your NLS code page setting to :65001 -unicode (UTF-8)
AND NLS_SEMANTICS TO BYTE

Also go to Reportcaster configuration and set the parameter :
Dsever Code page to 65001
Webserver Code page to 65001
and ZIPENCODING TO cp858

Are you realy working in UTF-8?

We've tried, but UTF-8 makes impossible :
a) Developer Studio
b) Report/Graph Assistant

(Power Painter was not tried)

We can live wo Developer Studio, but our users can't live wo BI Dashboard self-services.

Hi,

We are using webfocus in all our companies in Europe. And as you can imagine there are some characters that were not displayed and printed correctly: German, Hungarian,Polish.
We solve this issue by doing that setup I described.

Hi Majid,

Are your users have BI Dashboard self-service tools: Report Assistant, Power Painter?
Or you just make reporting for them?

It may or may not work, but I know it isn't necessary to change to UTF-8. We do not have those settings, and everything displays correctly. Since it does introduce some problem with some tools as Ingas mentions, I wouldn't got there unless nothing else works.

Thanks for everyone's input on this issue it is greatly appreciated! Darin, I ran the test procedure with the field inserted in the heading and it displays as Ba?uelos. If I type Bañuelos in the heading it appears fine. When using SQLPLUS to query the data, it appears incorrectly. When I use Quest's TOAD to run the query, it appears correctly.

Sorry, I forgot to mention that the database is Oracle 9i

quote:

the database is Oracle 9i

This might be the problem and is a good example of why should everybody update there signature..

If you do we all can see your platform and help better!

Por favor....

Obviously I misunderstood the function of the signature in the profile. Since there is a place in the profile to enter the application versions and platform information, I presumed that signature was for signature. I have updated it with the requested information.

Thanks!

Christine,
A common mistake on the signature thing - I hear IB is working on clarifying this. Back to the question-

If SQLPLUS can't retrieve the data correctly, I would not expect WF's Oracle driver to work either. Very interesting that a third-party SQL tool would work when Oracle's own tool will not.

Since it appears to be an issue entirely related to the database, I would definitely open a case on this one with IBI (and probably with Oracle as well.) The issue does not appear with our DB2/UDB data. Good luck!

Hi Ingas,

We are just making reports to them.Our ERP system is also sending official documents to our customers everywhere in Europe.An some of them they either a legalname or address or city that contains in general special letters.

Majid.

Hi,

I am also facing a similar problem. In my case, oracle containing name has some german character "Lübberstedt". When the report is populated with this data. It is printed as "Lübberstedt". The current NLS_lang setting on my reporting server(installed on AIX 5.3) is
LANG = AMENGLISH
CODE_PAGE = 437

The report from same database is populated correctly on my localhost on Windows XP with the same NLS_lang settings.
I tried changing CODE_PAGE to 65001 but still it doesn't work.
Please suggest.

I run my procedure on webconsole with code_page set to 65001 and it gave me right value but when I run it from MRE, some square box starts coming.

cburrell & chirag, what are the Oracle environment settings in the box where the WF server runs?

In our environment, we needed to set NLS_LANG appropriately in order to retrieve extended characters from the database back to WF.

This is our setting:

NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1

- Neftali.

The aforementioned solution is documented here!

Hope that helps!

- Neftali.

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

NLS settings must be set on BOTH the WF Server AND the WF Client. You should probably be using code page 137.

I have set 65001 on WF server console and WF client but still HTML report not getting displayed with correct name though the excel report is coming with correct name. I am using IHS 6.0 and WAS 6.0 as webserver and application server respectively. Is there specific setting i have to do on these servers also.


Regards,
Chirag
(local : WF714, tomcat, windows)
(environment : WF714, WAS6.0, IHS 6.0, UNIX AIX 5.3)

65001 != 137

I concur. As soon as you are dealing with characters above 127 (80 in hex), and you are using "Western data", change your server to code page 137. That is usully ALL you have to do.