This discussion is archived
3 Replies Latest reply: Nov 15, 2013 5:43 PM by Christian Erlinger RSS

Forms 10g + UTF8 - NLS_LANG=AMERICAN_AMERIC.UTF8

T. Morton Newbie
Currently Being Moderated

Hello,

 

When I compile fmb on OAS 10 g (10.1.2.3.0) on Linux and connected to a DB 11g with UTF8, do I have to specify the NLS_LANG=AMERICAN_AMERICA.UTF8 ?

Does the compiler use this variable during compilation ?

 

At the moment, I specify 2 variables before compiling:

export NLS_LANG=AMERICAN_AMERICA.UTF8

export NLS_LENGTH_SEMANTICS=CHAR

 

but I face some problems because of that.

Others developpers on the same server with same DB 11g in UTF8 specify the NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1 and does not have any problem ?!

 

Thanks in advance.

Tim.

  • 1. Re: Forms 10g + UTF8 - NLS_LANG=AMERICAN_AMERIC.UTF8
    Christian Erlinger Guru
    Currently Being Moderated

    Well, IMO the NLS_LANG and NLS_LENGTH_SEMANTICS should be set on linux as well, but unfortunately I have no linux machine to double check. What problems do you encounter? Do you get some unexpected Numeric or Value errors and something like that, or do you get squares instead of UTF-8 characters on the client side?

     

    cheers

     

    EDIT: ah, and of course we are talking about the very same forms as here: Forms 10g truncates data when NLS_LANG=UTF8

    meaning no data length semantics set at item level?

  • 2. Re: Forms 10g + UTF8 - NLS_LANG=AMERICAN_AMERIC.UTF8
    T. Morton Newbie
    Currently Being Moderated

    Yes we are talking about the same forms with no data length semantics set at item level.

    For the variable NLS_LENGTH_SEMANTICS=CHAR, it's pretty clear for me.

    Forms uses this variable at compile time as a default value for SEMANTIC property when nothing is specified at item level.

     

    But for NLS_LANG, I doubt the need of specifying it at compile time.

    Does forms will use it at compile time ?!

    I understand that we need to specify it in the default.env while running the forms.

     

    I currently face a bug as explain here Forms 10g + UTF8 - Item displays #### when it's content are too long

    It seeams thaht the bug is related to the NLS_LANG and I was wondering if I really need to specifiy the NLS_LANG at compile time because other developpers on the same server specifiy the NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1 and does not have any problem...

    What is the good practice for this NLS_LANG ?

     

    I will do some tests with different NLS_LANG and keep you in touch.-> So after some tests, it appears that NLS_LANG is not usefull at compile time.

     

    Regards,

  • 3. Re: Forms 10g + UTF8 - NLS_LANG=AMERICAN_AMERIC.UTF8
    Christian Erlinger Guru
    Currently Being Moderated

    That would depend. You need to run your forms with the same characterset you compile them. So you won't be able to enter e.g. chinese characters in your form if you compile and run them with a west european characterset. For that you'd need to compile your form with a chinese characterset or use UTF-8 as client characterset.

    There is no need for the client characterset to match the database characterset; however it will limit the data you are able to enter. You'll be much more flexible with AL32UTF8 (or UTF8 in your case) as a client characterset as you won't have to care if the user enters chinese, russian, arabic or west european characters. If this has no use to you then you shouldn't have a problem setting NLS_LANG to AMERICAN_AMERICA.WE8ISO9959P1.

     

    cheers

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points