Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

National/regional settings not set correctly #56

Closed
jgebal opened this Issue Dec 4, 2017 · 12 comments

Comments

Projects
None yet
3 participants
@jgebal
Copy link
Member

jgebal commented Dec 4, 2017

@tkleiber reported to em that, when running client on machines using different language, date&number format, they run into issues. Client seems to ignore local machine settings and this leads to their code running into some issues.

I hope to get more details on the type of issues they face and reasons for that.
It would be good to investigate the effort needed for the client to use local-machine language, date&number settings either from system (most preferable) or from NLS env parameters (if set).

@pesse

This comment has been minimized.

Copy link
Member

pesse commented Dec 4, 2017

NLS for country and language should be not too hard to get in - we'll have to adjust the bat/shell files though. Have to investigate if appassembler provides options for that kind of stuff.

Which other NLS env parameters would we want to use from environment?

@jgebal

This comment has been minimized.

Copy link
Member Author

jgebal commented Dec 4, 2017

Language and region should be enough. Rest of the settings should be derived from those two I think.

@pesse pesse self-assigned this Dec 4, 2017

@tkleiber

This comment has been minimized.

Copy link

tkleiber commented Dec 4, 2017

Yes I for the moment I think that language and region should be mapped to NLS_LANG.

It seems that oracle has dropped the support for NLS variable with version 10 of the odbc drivers.

Before the jvm variable user.language (which derives from LANG or LC_ALL) would set NLS variables accordingly.

Further there was at least till 10g a InitializationString parameter in the connect string, which allows any sql commands to do such initialization (which would help us with another issue): https://docs.oracle.com/cd/E13222_01/wls/docs103/jdbc_drivers/oracle.html

@tkleiber

This comment has been minimized.

Copy link

tkleiber commented Dec 4, 2017

Testcase, which fails on our (german) environment, as it does deliver a comma instead the point as decimal character:
ut.expect(to_char(24566698.76)).to_equal('24566698.76');

Have tried following before calling cli without success:
export LANG=en_US.utf-8
export LC_ALL=en_US.utf-8
export _JAVA_OPTIONS=-Duser.language=en

@pesse

This comment has been minimized.

Copy link
Member

pesse commented Dec 4, 2017

Thanks for the testcase, will investigate

@jgebal

This comment has been minimized.

Copy link
Member Author

jgebal commented Dec 4, 2017

Hmmm.
Just wondering. Do you use a lot of to_char / to_date with default NLS format in your code?
Is this test case presented just to ensure pose the issue or are you actually using to_char in ut.expect?

@tkleiber

This comment has been minimized.

Copy link

tkleiber commented Dec 4, 2017

Just to ensure pose the issue. A real world example is eg. invoices to customers in it's user defined preferences, which are not the session parameters and to ensure that session parameters does not influence the output.

@pesse

This comment has been minimized.

Copy link
Member

pesse commented Jan 14, 2018

@tkleiber can you tell me if you experience that problem on windows or linux? I investigated it and could reproduce the situation on windows. The main problem is that jvm seems to get the wrong locale, no matter if you set LC_ALL as environment variable or not (always gets the system locale which in my case is de_DE, too).
I can (an maybe will) introduce command line parameters to just override Locale, but I'd like to investigate the problem a bit deeper before

@tkleiber

This comment has been minimized.

Copy link

tkleiber commented Jan 14, 2018

I have seen this on SLES 11, this is a 64bit linux.

@pesse

This comment has been minimized.

Copy link
Member

pesse commented Jan 14, 2018

@tkleiber I have no clues why JVM doesn't react to LC_ALL setting in your (and my case), but I managed to change the locale and therefore the database NLS settings by adding the following to environment:

export JAVA_TOOL_OPTIONS=-Duser.country=us -Duser.language=en

Can you verify this is working in your environment?
I could add a new commandline parameter "-locale=en_US.utf-8" of course, but this is a general JVM topic and I can imagine something like this would rather increase the confusion.
What's the opinion of the others, @jgebal , @viniciusam ?

@jgebal

This comment has been minimized.

Copy link
Member Author

jgebal commented Jan 15, 2018

I would askTom. They definitely have it solved in SQLCL and SQLDeveloper.

pesse added a commit that referenced this issue Jan 15, 2018

@pesse pesse closed this in #59 Jan 16, 2018

pesse added a commit that referenced this issue Jan 16, 2018

Merge pull request #59 from utPLSQL/bugfix/nls_from_environment
Added locale initialization from environment variables NLS_LANG, LC_ALL or LANG

Fixes #56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.