In one of our Apex-like application user reported a HTTP 400 error after clicking on a button that invokes PL/SQL procedure. At first glance I suspected a missing execute privilege but the quick look at Oracle HTTP log revealed the true reason:
X:\ORACLE\OFM\OFM11\instances\instance1\diagnostics\logs\OHS\ohs1\ohs1.log)

[2016-05-04T10:58:23.9709+02:00] [OHS] [ERROR:32] [OHS-9999] [core.c] [host_id: ACMEHOST] [host_addr: 10.10.10.11] [pid: 5048] [tid: 1816] [user: SYSTEM] [VirtualHost: main]  MODPLSQL-00359: mod_plsql: /sales/!appschema.orderentry.program HTTP-400 Too many arguments passed in(2002). Limit is 2000, referer: http://ohs.acme.com/sales/!appschema.orderentry.program

-> HTTP-400 Too many arguments passed in(2002). Limit is 2000
.. so, the reason for the error is the default limit in mod_plsql on the number of parameters that can be passed to the pl/sql procedure.

A search on MOS confirmed by suspicion, please refer to:

Modplsql application throws “HTTP-400 Too many arguments passed in. Got 7076 parameters. Upper limit is 7000” (Doc ID 386946.1)

After adding directive “PlsqlMaxParameters 4000” to the plsql.conf and restarting the http listener (cmd> opmnctl restartproc process-type=OHS), the problem was solved.
Our plsql.conf looks like this:

X:\ORACLE\OFM\OFM11\instances\instance1\config\OHS\ohs1\moduleconf\plsql.conf

# ============================================================================ 
#                       mod_plsql configuration file                           
# ============================================================================ 
# 1. Please refer to plsql.README for a description of this file               
# 2. Parameters in this file have to be configured manually                    
# ============================================================================ 

# Configure Oracle HTTP Server to load mod_plsql
LoadModule plsql_module ${ORACLE_HOME}\ohs\modules\mod_plsql.dll

# Load in mod_plsql directives only if mod_plsql is loaded
<IfModule mod_plsql.c>

# ============================================================================ 
# Global Settings Section : Directives that apply to all DADs
# ============================================================================ 

PlsqlLogEnable on

PlsqlLogDirectory "${ORACLE_INSTANCE}\diagnostics\logs\${COMPONENT_TYPE}/${COMPONENT_NAME}"

# 4.5.2016 -- (see MOS ID 386946.1)

PlsqlMaxParameters 4000

# PlsqlIdleSessionCleanupInterval 15 (default)

# PlsqlDMSEnable On (default)

# ============================================================================ 
# Database Access Descriptors Settings Section
# ============================================================================ 
include "${ORACLE_INSTANCE}\config\${COMPONENT_TYPE}\${COMPONENT_NAME}\mod_plsql\dads.conf"

# Custom DAD's for Acme.com
include "${ORACLE_INSTANCE}\config\${COMPONENT_TYPE}\${COMPONENT_NAME}\mod_plsql\marvel.conf"

# ============================================================================ 
# Cache Settings Section
# ============================================================================ 
include "${ORACLE_INSTANCE}\config\${COMPONENT_TYPE}\${COMPONENT_NAME}\mod_plsql\cache.conf"

</IfModule>

We’re pleased that Oracle fixed the issue with the ODP.NET managed driver in the newly released ODAC 12c Release 4, that prevented us to use Oracle Wallet as a password store in the past. We have several .NET applications that’re read-only, intended to be used by multiply end users. Users don’t need personal database accounts. Instead, we want our application to read app-user credentials from Oracle Wallet.
Until ODAC 12c Release 4 we were unable to use ODP.NET managed driver with Oracle Wallet file method. The issue that we had was limited to the managed driver, unmanaged driver has no problem reading Oracle Wallet password store.
After we saw new feature announcement on page 3: Secure External Password Store SEPS….”ODP.NET, Managed Driver supports storing password credentials using SEPS.”, we decided to test this.

We created and configured Oracle Wallet:

cmd> mkstore -wrl D:\OW\ACME  -create
cmd> mkstore -wrl D:\OW\ACME -createCredential apptns appuser apppassword

Then we configured sqlnet.ora:

SQLNET.AUTHENTICATION_SERVICES = (NONE)
NAMES.DIRECTORY_PATH= (TNSNAMES)
WALLET_LOCATION = (SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=D:\OW\ACME)))
SQLNET.WALLET_OVERRIDE = TRUE

and tnsnames.ora:

APPTNS = 
  (DESCRIPTION = 
    (ADDRESS_LIST = 
       (ADDRESS = 
         (PROTOCOL = TCP)
         (HOST = acmedb.host.com)
         (PORT = 1521)
       )
    )
    (CONNECT_DATA =
       (SID = ACME)
    )
  )

Finally we tested the connection with:

sql> connect /@apptns
Connected.

So far, so good. Oracle Wallet is prepared to be used by .NET application with managed driver 12c Release 4.
We saved sqlnet.ora and tnsnames.ora in the same directory with Oracle Wallet files. Relevant part of the application config looked like this:

<oracle.manageddataaccess.client>
    <version number="*">
	  <settings> 
		<setting name="TNS_ADMIN" value="D:\OW\ACME"/>
                <setting name="TraceLevel" value="7" />
                <setting name="TraceOption" value="1"/> 
		<setting name="TraceFileLocation" value="D:\TRACE" />
	  </settings>
	</version>
  </oracle.manageddataaccess.client>

Just for the record, we could set everything (sqlnet.ora parameters + tns alias) in app.config as well:

  <oracle.manageddataaccess.client>
    <version number="*">
      <settings>
        <setting name="TraceLevel" value="7" />
        <setting name="TraceOption" value="1"/> 
        <setting name="TraceFileLocation" value="D:\TRACE" />
        <setting name="SQLNET.AUTHENTICATION_SERVICES" value="null" />
        <setting name="WALLET_LOCATION" value="(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=D:\OW\ACME)))" />
        <setting name="SQLNET.WALLET_OVERRIDE" value="TRUE" />
        <setting name="NAMES.DIRECTORY_PATH" value="(TNSNAMES)" />
      </settings>
      <dataSources>
        <dataSource alias="APPTNS" descriptor="APPTNS = (DESCRIPTION =(ADDRESS_LIST=(ADDRESS =(PROTOCOL = TCP)(HOST = acmedb.host.com)(PORT = 1521)))(CONNECT_DATA=(SID=ACME)))"/>
      </dataSources>
    </version>
  </oracle.manageddataaccess.client>

For the purpose of testing managed driver with Oracle Wallet, we wrote simple applet that takes Username, Password and TNS alias from the end user:

displays connection string:

and displays a message “Connection Opened!” if login was successful. But instead, we’re surprised by ORA-01017 error:

I will spare you with all the dirty details of troubleshooting that we went through, finally we decided to turn on sqlnet trace by adding three parameters to the app.config, namely; TraceLevel, TraceOption and TraceFileLocation (note that Oracle documentation at the time of this writing has a typo: TraceFileLocations. Note the “s”, this is wrong!).

And found this:

2015-11-25 13:08:47.270153 TID:3   (PRI) (CP) OracleConnectionImpl.Connect() OracleConnectionImpl.Connect => Querying Data Source:APPTNS
2015-11-25 13:08:47.291153 TID:3   (NET) (SQLNET) SEPS userid is null.
2015-11-25 13:08:47.291153 TID:3   (NET) (SQLNET) SEPS password is null.

What the hack? We have APPTNS in our Oracle Wallet. Or do we?

cmd> mkstore -wrl D:\OW\ACME -listCredential
Oracle Secret Store Tool : Version 12.1.0.2
Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights reserved.

Enter wallet password:
List credential (index: connect_string username)
1: apptns appuser

Is it possible that managed driver is handling tns alias in case sensitive manner? Bingo.
Even thought it doesn’t matter how you connect with the sqlplus, like:

sqlplus /@APPTNS
sqlplus /@apptns
sqlplus /@Apptns
...

in all three cases login will succeed. Not so with ODP.NET managed driver. You have to specify tns alias precisely with the properly cased string,
as it was used while adding credential to the Oracle Wallet. Is it a bug or a feature? I guess both.

Also, be careful how you compile, if your target is 64 bit OS, then use x86 or AnyCPU as a target. We were out of luck trying to compile for x64 target, meaning that application must run as a 32-bit process, even on 64-bit OS, otherwise Oracle Wallet won’t work.