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?
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?
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.
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.