The offset field of executeMany's result has just 16 bits

[lmcarreiro]

1. With the async/await programming style, make sure you are using 'await' in the right places.
   Ok

2. Is it an error or a hang or a crash?
   Error

3. What error(s) you are seeing?

// ... inside an async function
const size = 65538;
const arr = new Array(size).fill([0]);
arr[size-1] = [1];
arr[size-2] = [1];
arr[size-3] = [1];
arr[size-4] = [1];
const result = await executeMany({ // this executeMany is a function that creates a connection, calls executeMany and closes the connection after executeMany returns
  query: `
    update ANY_TABLE
    set ANY_COLUMN = null
    where 0 = 1
      or 0 = (select case when :0 = 0 then 1 else 0/0 end as XXX from dual)
  `,
  parameters: arr
});
console.log(result);

Created an array with 65538 elements, and forced an error to occur at the four last positions: 65534, 65535, 65536 and 65537. In the result, the first two is ok, 65534 and 65535. But the next two shoud be 65536 and 65537, not 0 and 1.

It is returning in the offset field just the 16 less meaning bits.

Result of console.log:

{ rowsAffected: 0,
  batchErrors:
   [ { Error: "ORA-01476: divisor is equal to zero", errorNum: 1476, offset: 65534 },
     { Error: "ORA-01476: divisor is equal to zero", errorNum: 1476, offset: 65535 },
     { Error: "ORA-01476: divisor is equal to zero", errorNum: 1476, offset: 0 },
     { Error: "ORA-01476: divisor is equal to zero", errorNum: 1476, offset: 1 } ] }

So, if I'm using executeMany with bigger arrays, I'll never be sure which input caused an error.

4. Include a runnable Node.js script that shows the problem.
   Include all SQL needed to create the database schema.
   node script.js

5. Run node and show the output of:

process.platform: win32
process.version: v10.15.3
process.arch: x64
require('oracledb').versionString: 3.1.2

6. What is your Oracle Database version?

-- select * from v$version
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
PL/SQL Release 12.2.0.1.0 - Production
"CORE	12.2.0.1.0	Production"
TNS for Linux: Version 12.2.0.1.0 - Production
NLSRTL Version 12.2.0.1.0 - Production

[danilohgds]

It could be due to be a mismatch in types used between odpi-c layer and the NAN api in oracledb code.

in ODPI-C offset is uint16_t in class dpiErrorInfo, while in lib, Nan::Newv8::Number, double... probably switching the type to v8:Uint16 might do the trick...

[anthony-tuininga]

ODPI-C currently has this value as 16-bit. It should probably be changed to 32-bit, but that will take a bit of effort in order to retain backwards compatibility. In the meantime, please use batches of less than 65536 entries!

[lmcarreiro]

If it will get some time to fix, maybe a warning in the docs would help. I would put it in these two locations:
https://oracle.github.io/node-oracledb/doc/api.html#executemanyoptbatcherrors
https://oracle.github.io/node-oracledb/doc/api.html#-213-offset

[anthony-tuininga]

I've pushed the necessary changes through to ODPI-C (on which node-oracledb depends). You can build node-oracledb yourself with the updated ODPI-C or wait for it to be included in the official release whenever that is made.

[cjbj]

@lmcarreiro the necessary ODPI-C change was picked up by node-oracledb 4.2, which is now available. Thanks for reporting the issue.