I am trying to resolve an ORA-01882 exception that is being thrown by an application running in IIS connecting via unmanaged .NET DataAccess DLLs to an Oracle 19c DB running in AWS RDS. The app has a PetaPoco ORM layer wrapping all DB access. There is one schema used. Developers building the application can connect to the schema, and run through the application without issues. However, when the application is deployed to a dev/test environment in AWS (we use an Elastic Beanstalk environment running Windows Server 2016, IIS 10)… the application fails when trying to complete a create project action. If fails with the ORA-01882 exception.
I am able to set the EC2 instance timezones without issue. I have tried setting a ‘TZ’ environment variable, exception still occurs. Setting the ORA_SDTZ environment variable does result in a change to the SESSIONTIMEZONE value, from an offset to a named TIMEZONE, but still throws the exception.
The Database seems fine as several developers have been able to use the schema to run local copies of the app without failure. The AWS Elastic Beanstalk EC2 instance is the only location the exception is thrown… and this is prohibiting our QA staff from progressing through the application past the feature that is throwing the exception.
I see a number of posts online regarding this exception, with different suggestions on how to resolve. The only one I see from Oracle is to use the ‘UseHourOffsetForUnsupportedTimezone’ property on the connection object, but this has been problematic because of the PetaPoco ORM layer wrapping all DB access.
I'm sure this is likely a simple configuration issue on the EC2 instance… and I think I have tried them all.
What is the logic being performed by the unmanaged Oracle Access module that triggers this exception. What are the configuration items that must be set to avoid the exception. Most docs seem to point to a change required on the database, but we have developers who are able to run the application, connnecting to the same schema, with throwing the exception…. so our case SEEMS to be a local configuration issue.