import * as fs from 'fs';
import * as oracledb from 'oracledb';
module.exports = async function (context: any, req: any) {
    context.log('This is a new function.');
    oracledb.initOracleClient();
    context.res = {
        // status: 200, /* Defaults to 200 */
        body: {
            "platform": process.platform,
            "version": process.version,
            "arch": process.arch,
            "oracleVersion": oracledb.versionString,
            "clientVersion": oracledb.oracleClientVersionString,
    return context;
Locally, I can get this to work with a local.settings.json like:
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "node",
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "ORACLE_DATABASE_NAME": "",
    "ORACLE_DATABASE_HOST": "",
    "ORACLE_DATABASE_USER": "",
    "ORACLE_DATABASE_SERVICE": "",
    "ORACLE_DATABASE_PASSWORD": "",
    "ORACLE_DATABASE_PORT": "1521",
    "LD_LIBRARY_PATH": "/home/damien/path/to/client",
    "DPI_DEBUG_LEVEL": 64
However, when I tried the exact same setup in Azure Functions (I confirmed the instantclient's *.so are uploaded correctly to the right location both via manual inspection and via a script like:
import * as fs from 'fs';
console.log(process.env['LD_LIBRARY_PATH']);
const files = fs.readdirSync(process.env['LD_LIBRARY_PATH'] ?? process.cwd());
console.log(files);
For clarity, for me, my settings across the envs in question are:
LD_LIBRARY_PATH - Azure Functions (locally):  /home/damien/projects/dist/packages/project/oracle-instant-client
Instaclient Location - Azure Functions (locally): /home/damien/projects/dist/packages/project/oracle-instant-client
== Version 1
LD_LIBRARY_PATH - Azure Functions (PaaS): /home/site/wwwroot/oracle-instant-client
Instaclient Location - Azure Functions (PaaS): /home/site/wwwroot/oracle-instant-client
== Version 2 via a file mount
LD_LIBRARY_PATH - Azure Functions (PaaS): /opt/oracle-instant-client
Instaclient Location - Azure Functions (PaaS): /opt/oracle-instant-client
I tried the debug setting DPI_DEBUG_LEVEL: 64 and locally I see a successful load:
[2023-10-08T20:02:01.414Z] ODPI [26713] 2023-10-08 16:02:01.412: ODPI-C 5.0.0
[2023-10-08T20:02:01.414Z] ODPI [26713] 2023-10-08 16:02:01.412: debugging messages initialized at level 64
[2023-10-08T20:02:01.414Z] ODPI [26713] 2023-10-08 16:02:01.412: Context Parameters:
[2023-10-08T20:02:01.414Z] ODPI [26713] 2023-10-08 16:02:01.412: Environment Variables:
[2023-10-08T20:02:01.415Z] ODPI [26713] 2023-10-08 16:02:01.412:     LD_LIBRARY_PATH => "/home/damien/project/dist/packages/oracle-instant-client"
[2023-10-08T20:02:01.415Z] ODPI [26713] 2023-10-08 16:02:01.412: check module directory
[2023-10-08T20:02:01.415Z] ODPI [26713] 2023-10-08 16:02:01.412: module name is /home/damien/project/dist/packages/esg-read-api/build/Release/oracledb-6.1.0-linux-x64.node
[2023-10-08T20:02:01.415Z] ODPI [26713] 2023-10-08 16:02:01.412: load in dir /home/damien/project/dist/packages/esg-read-api/build/Release
[2023-10-08T20:02:01.415Z] ODPI [26713] 2023-10-08 16:02:01.412: load with name /home/damien/project/dist/packages/esg-read-api/build/Release/libclntsh.so
[2023-10-08T20:02:01.416Z] ODPI [26713] 2023-10-08 16:02:01.412: load by OS failure: /home/damien/project/dist/packages/esg-read-api/build/Release/libclntsh.so: cannot open shared object file: No such file or directory
[2023-10-08T20:02:01.416Z] ODPI [26713] 2023-10-08 16:02:01.412: load with OS search heuristics
[2023-10-08T20:02:01.416Z] ODPI [26713] 2023-10-08 16:02:01.412: load with name libclntsh.so
[2023-10-08T20:02:01.421Z] ODPI [26713] 2023-10-08 16:02:01.421: load by OS successful
[2023-10-08T20:02:01.421Z] ODPI [26713] 2023-10-08 16:02:01.421: validating loaded library
However, comparing that with the Azure Function logs with debugging enabled gives me:
"ODPI [00088] 2023-10-08 20:24:31.060: ODPI-C 5.0.0"
"ODPI [00088] 2023-10-08 20:24:31.061: debugging messages initialized at level 64"
"ODPI [00088] 2023-10-08 20:24:31.062: Context Parameters:"
"ODPI [00088] 2023-10-08 20:24:31.062: Environment Variables:"
"ODPI [00088] 2023-10-08 20:24:31.062:     LD_LIBRARY_PATH => ""/opt/oracle-instant-client"""
"ODPI [00088] 2023-10-08 20:24:31.062: check module directory"
"ODPI [00088] 2023-10-08 20:24:31.062: module name is /home/site/wwwroot/build/Release/oracledb-6.1.0-linux-x64.node"
"ODPI [00088] 2023-10-08 20:24:31.062: load in dir /home/site/wwwroot/build/Release"
"ODPI [00088] 2023-10-08 20:24:31.062: load with name /home/site/wwwroot/build/Release/libclntsh.so"
"ODPI [00088] 2023-10-08 20:24:31.063: load by OS failure: /home/site/wwwroot/build/Release/libclntsh.so: cannot open shared object file: No such file or directory"
"ODPI [00088] 2023-10-08 20:24:31.063: load with OS search heuristics"
"ODPI [00088] 2023-10-08 20:24:31.063: load with name libclntsh.so"
"ODPI [00088] 2023-10-08 20:24:31.063: load by OS failure: libclntsh.so: cannot open shared object file: No such file or directory"
"ODPI [00088] 2023-10-08 20:24:31.063: load with name libclntsh.so.19.1"
"ODPI [00088] 2023-10-08 20:24:31.063: load by OS failure: libclntsh.so.19.1: cannot open shared object file: No such file or directory"
"ODPI [00088] 2023-10-08 20:24:31.063: load with name libclntsh.so.18.1"
"ODPI [00088] 2023-10-08 20:24:31.063: load by OS failure: libclntsh.so.18.1: cannot open shared object file: No such file or directory"
"ODPI [00088] 2023-10-08 20:24:31.064: load with name libclntsh.so.12.1"
"ODPI [00088] 2023-10-08 20:24:31.064: load by OS failure: libclntsh.so.12.1: cannot open shared object file: No such file or directory"
"ODPI [00088] 2023-10-08 20:24:31.064: load with name libclntsh.so.11.1"
"ODPI [00088] 2023-10-08 20:24:31.064: load by OS failure: libclntsh.so.11.1: cannot open shared object file: No such file or directory"
"ODPI [00088] 2023-10-08 20:24:31.064: load with name libclntsh.so.20.1"
"ODPI [00088] 2023-10-08 20:24:31.064: load by OS failure: libclntsh.so.20.1: cannot open shared object file: No such file or directory"
"ODPI [00088] 2023-10-08 20:24:31.065: load with name libclntsh.so.21.1"
"ODPI [00088] 2023-10-08 20:24:31.065: load by OS failure: libclntsh.so.21.1: cannot open shared object file: No such file or directory"
I also created Azure/azure-functions-core-tools#1620 (comment) as this may be on the Azure side, but I'm not 100% sure the internals of the v6 binaries.
Unfortunately, at this point, I didn't know where to look further. It feels as though:
There's a mystical lookup function included in the pre-compiled binaries that I don't understand that excludes my directory on Azure functions.
Azure functions filesystem operates "differently" in a way that I do not understand.
true === false results in true
Azure Linux Functions library will not find specified file
Azure Linux Functions Error: DPI-1047 Cannot locate a 64-bit Oracle Client library
    Oct 8, 2023
          
Thanks for reporting this. Based on the logs, it seems that the underlying ODPI-C library does not pickup the LD_LIBRARY_PATH for fetching libclntsh.so, when called through Azure functions.
We will investigate this and get back to you.
          
I would assume so. I wound up just spinning up a docker container based upon mcr.microsoft.com/azure-functions/node:4-node18 that does actually function properly with the LD_LIBRARY_PATH. I suspect that this is something specific to Azure functions, but depending on whether or not the team cares to support the Azure Functions model, you may or may not want to investigate it further.
I can provide any further information you may need, but my C is weak at best and I got to LoadLibrary in the ODPI and then gave up as I don't know what that function does internally.
          
LoadLibrary is an windows API called by ODPI. GetLastError is dumped in odpi code. I think any application doing dlopen seems to have some permissions/setting  issue.  Can we also run under Linux which uses dlopen
Does thin mode work for your application? I mean  If you remove  oracledb.initOracleClient(); call from your application,  driver runs in thin mode.
          
I strugle with the same issue. Any solution? I can only use thick mode Azure deployment, but can't run because of the missing instant oracle client. If I install it with ssh then the new deployment removes it from /oracle directory.
Azure web app -> Linux plan
          
@flash4174  Can you tell, what is the new deployment that removes Oracle Instant Client from the /oracle directory?
Are you saying that installing node-oracledb via npm removes Oracle Instant Client from the oracle?
          
@sharadraju I install Oracle Instant Client with ssh with wget and unzip to /oracle folder
Then I redeploy my site with local git and after that if I check the folder with ssh, it not exist.
Does the oracledb library should have the instant client by default?
          
Thanks @flash4174  for the explanation.

When you redeploy your site, there may be other modules that could have erased the /oracle directory.

Node-oracledb will not remove the /oracle directory and as of version 6.0 does not require Oracle Instant Client to get started.
If you want to use Thick mode, Oracle Instant Client is required.
I would suggest that you raise this issue with Azure.

See #1611 (comment) for the OP's comments on Azure functions.