RE: Different date formats between thin and thick clients

From: <rajendra.pande_at_ubs.com>
Date: Tue, 22 Feb 2011 09:43:32 -0500
Message-ID: <D4C8B99EB96F2C42B4E19A3B87664F5EE6B4C6_at_NSTMC612PEX.ubsamericas.net>



Sandra  

Problem is that the thin driver does not use NLS  

Based on what I know this should work as this is one of the options suggested by ORACLE (115001.1) - depending on the version of the driver in use. See the referred note for 9I and 10G  

I was however wondering if you could share as to why are you switching from oci to thin. (I am assuming that when you say oci you mean the thick driver)  

Thanks


From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Sandra Becker Sent: Monday, February 21, 2011 2:05 PM
To: oracle-l
Subject: Different date formats between thin and thick clients  

Platform - IBM s/390

OS - SUSE Linux 10

Oracle - EE 10.2.0.4  

We have been moving our application from 9.2 thick client to 11.2 thin client. Along the way we broke parts of the application because the date format is different depending on the client used. The suggestion is to use an after logon trigger to set the date format correctly but that in turn will break something else. The application is pretty convoluted and badly documented so we're not sure we know every place that will break with a logon trigger. Every piece of the app logs into the database with the same userid.  

Here's what a developer gave me from a test he ran to show the format differences:  

                     | using oci 9.2             | using thin

NLS_DATE_FORMAT         | Mon DD YYYY HH24:MI:SS       | DD-MON-RR

 

 

Our latest brainstorm produced the following plan:  

  1. Create a new database user to be used by ONLY the piece of the application that is currently broken. This piece of the app has only 1 function, a very limited scope.
  2. Create an after logon trigger for the new userid to correctly set the date format.
  3. Make the necessary application configuration changes to login to the database with the new userid.
  4. Test, test, test, and test again.

Does anyone see any problems with this approach or any suggestions?

-- 
Sandy
Transzap, Inc.





Please visit our website at http://financialservicesinc.ubs.com/wealth/E-maildisclaimer.html for important disclosures and information about our e-mail policies. For your protection, please do not transmit orders or instructions by e-mail or include account numbers, Social Security numbers, credit card numbers, passwords, or other personal information. -- http://www.freelists.org/webpage/oracle-l
Received on Tue Feb 22 2011 - 08:43:32 CST

Original text of this message